Thank you for your post.
This was reported with FileMaker Server 9, and supposedly fixed in FileMaker Server 10. However, that doesn't seem to be the case.
I would first uninstall FileMaker Server 10 and reinstall it. Also, check your database files to make sure there is no corruption. Do you have any reference to external files? Do your clients encounter this behavior on a consistent basis? Can you ask your clients when do they first notice this problem? Do they recall what was occurring just before this behavior? Are they usually the same clients exhibiting this behavior? Or, is everyone showing up twice at one time or another? Are all clients running Windows computers? The users who show up the most, anything specific about their machine configuration that stands out from the others?
Any other information/clues you can provide may be helpful in narrowing down the possibilities.
Not fixed in Server 11 Advanced either. We too are running on Windows 2003 server (64-bit) and see duplicate users with 0 files open who cannot be disconnected. Users are on both PC and Mac. This begins to happen within a week of a server reboot and gradually builds up as more and more duplicate users appear.
I am just now connecting this issue to periodic crashes we have in which the server Event Log records the message "User X no longer responding, conneciton closed" for dozens of users at a time, freezing access to the files.
We have uninstalled and reinstalled the Server 11A, we have reimported data into a clean clone, we have run recover on files to be sure they report "no problems found," and we have tracked down and eliminated the source of frequent authentication errors on the server (which do not seem related but still).
Would be interested in hearing if anyone associates the "duplicate user" problem wih crashes.
Updating my own post four hours later. The duplicate clients are the result of authentication errors. I have a file with user accounts with a temporary password set to require password change at log-on. When a user opens this file from a related file, an error an authentication error is logged in the server event log and a second instance of the user's name appears in the server console. (It also appears when using the command line interface command "fmsadmin list clients.")
The user's "ghost" name remains there after they log in, showing 0 files open. It cannot be disconnected.
Right now I have 21 users with one or more "ghosts." One user has two ghosts because she had two files where her account required a password change on log-in.
I am suspecting that the buildup of ghost users which cannot be disconnected is causing our periodic crashes when server tries to implement the rule of disconnecting after a specified idle time.
Tonight I will reboot the server to get rid of the duplicate clients and see how many appear tomorrow.
I have disabled the "disconnect after idle time."
I also have this same issue, but without the crashing or freezing. I am running FileMaker Server Advanced version 126.96.36.199 on a Windows Server 2008 R2 (64-bit). All the clients are on Windows using either Pro 11.0v1, Pro11.0v2, Pro Advanced 11.0v1, or Pro Advanced 11.0v2.
I have duplicate users with 0 files open. I've tried disconnecting them through the Admin Console and through the command line, but neither worked. I have the 'set maximum idle time allowed for FileMaker Clients' option set in FileMaker Server as well as the 'Disconnect user from FileMaker Server when idle' option in the client's Privilege Set, but that too does not appear to working correctly. The only way that I can get rid of the duplicate users is to restart the server.
The users with the duplicate connections have said that they close the database normally, and that their workstations haven't crashed.
I also have "authentication failed" errors in the log viewer. I'm not sure that's the cause of the problem because some users that have failed authentication can disconnect from the server just fine and reconnect without having a duplicate connection, but I will investigate it further.
Most of the users open the database through a launcher shortcut, but again, only some of the users are having the duplicate connection problem.
Some users have multiple older versions of FileMaker installed on their workstation, like versions 5 & 8, but they only use the current version (11) to open the database. That wouldn't contribute to this problem, would it?
Any help would be greatly appreciated.
Are you able to correlate the authentication errors with the ghost users? In other words, does every user who has a "0" also have an authentication error? I know the other way is not the case, because we have many more authentication errors than "0" users. But every one of my ghosts also has an authentication error that same day.
If you are using a launcher file that that requires the user to enter a password when it connects to the served file, you can get rid of that particular authentication error by enabling the Guest account on the launcher file, then set its File Options to open as Guest. (Then to maintain it of course you have to force it to open with the admin account.)
Today I saw the curious behavior of the number of ghost clients grow to 21 by early afternoon, then drop to 7 at the end of the day.
I am rebooting the server each night to get rid of them. Each day I whittle away at the authentication errors in hopes of totally eliminating the ghosts.
This problem started in June 2010, just after we upgraded from FMSA10 to FMS11. We upgraded from 10 because the console frequently did not work due to Java issues.
Not sure what's next. I don't think Ghostbusters are still in business.
In my case, the authentication errors are not related to ghost users. Everyone has these authentication errors because of the way the database log-ins are set up. We have a main database that users have to use a user name & password to open. This main database links to another database that opens using the admin account by default. So when the user logs in, FileMaker trys to open the linked database using the log-in info from the main database, and that's where the authentication errors come from.
My number of ghost clients do not disappear. It grows by maybe 10-15 a day. I've been trying to look for a pattern, but have not found one yet.
I will try updating the Server to the latest version (11.0v2) and see if this problem still persists.
I too am having the same problem. Only my problem of ghost sessions can come from FMP clients , PHP clients or even a scheduled script. So in the case of the scheduled script (which always uses the admin account) , then authentication will not be the problem. In the scheduled script scenario , I was not aware of it until 3 days after the script was run , yet the console was reporting that the script was still running (even with timeout on that particular script set to 10 minutes). This has become a major problem in our environment as the ghost sessions can cause record locking , which requires me to reboot the server... not good having to do that every few days... I hope someone comes up with a definitive answer soon as this looks like an old problem dating back to the FMS9 days , and still occurs today with FMS11.
Updating to version 188.8.131.52 did not resolve the ghost connection issue. However, I did confirm the cause of the ghost connections, and it is the same problem Bob is having. We require our users to change their passwords every X amount of days. If the user's password is expired, it will register in the logs as an "authentication failed" error, and when the user changes their password, FileMaker Server will create another connection for that user.
I hope FileMaker can fix this bug in the next version update.
I am glad to see that Eric can also link the ghost clients to authentication errors that happen when a user if forced to change a password. At least I am not the only one seeing this (on Windows Server 2003).
I can also confirm "Powerslave's" note that the ghost clients have mutiple causes, although since cutting down on authentication errors I am seeing them a lot less often. Today there are none (!), the other day there were seven but by evening they had gone away. Hadn't seen that before.
Does anyone see a link between the ghost clients and the event log message "X is no longer responding, connection closed?" These occur seemingly at random, but when they reach critical mass we get a server crash.
I am rebooting the server every night and have had no crash for 15 days, which is the fourth-longest interval since this problem started in June 2010.