jimbro1000

1.7.5 stopping while all screens locked

9 posts in this topic

I've just installed 1.7.5 onto a pair of windows 7 workstations and within minutes I have a problem If the server and client are both on a locked screen, moving the mouse (on the server) to the client monitor causes the client to throw a series of messages: [2015-11-23T11:19:00] WARNING: detected application not running, pid=4480 [2015-11-23T11:19:01] INFO: backing off, wait=2s, failures=1 [2015-11-23T11:19:03] INFO: starting new process [2015-11-23T11:19:03] INFO: activeDesktop:Default [2015-11-23T11:19:03] ERROR: could not get session id for process id 7164 [2015-11-23T11:19:03] INFO: starting new process [2015-11-23T11:19:03] INFO: drag and drop enabled [2015-11-23T11:19:03] NOTE: started client [2015-11-23T11:19:03] NOTE: connecting to '<server>': <server ip:port> [2015-11-23T11:19:03] INFO: watchdog status: ok [2015-11-23T11:19:03] NOTE: connected to server [2015-11-23T11:19:12] INFO: watchdog status: ok [2015-11-23T11:19:39] INFO: entering screen [2015-11-23T11:19:39] INFO: clipboard was updated [2015-11-23T11:19:39] INFO: clipboard was updated [2015-11-23T11:19:57] INFO: service command updated [2015-11-23T11:19:58] INFO: process started but command is empty, shutting down [2015-11-23T11:19:58] INFO: got ipc shutdown message [2015-11-23T11:19:58] INFO: leaving screen [2015-11-23T11:19:58] NOTE: stopped client [2015-11-23T11:19:59] INFO: process 2676 was shutdown gracefully [2015-11-23T11:21:59] INFO: starting client On the server the log is much the same story: [2015-11-23T11:18:43] INFO: switch from "<server>" to "<client>" at 0,742 [2015-11-23T11:18:43] INFO: leaving screen [2015-11-23T11:18:43] INFO: screen "<server>" updated clipboard 0 [2015-11-23T11:18:43] INFO: screen "<server>" updated clipboard 1 [2015-11-23T11:18:59] NOTE: client "<client>" has disconnected [2015-11-23T11:18:59] INFO: jump from "<server>" to "<client>" at 960,540 [2015-11-23T11:18:59] INFO: entering screen [2015-11-23T11:19:03] NOTE: accepted client connection [2015-11-23T11:19:03] NOTE: client "<client>" has connected [2015-11-23T11:19:38] INFO: switch from "<server>" to "<client>" at 0,698 [2015-11-23T11:19:38] INFO: leaving screen [2015-11-23T11:19:57] NOTE: client "<client>" has disconnected [2015-11-23T11:19:57] INFO: jump from "<client>" to "<server>" at 960,540 [2015-11-23T11:19:57] INFO: entering screen [2015-11-23T11:20:03] NOTE: stopped server [2015-11-23T11:20:03] WARNING: detected application not running, pid=320 [2015-11-23T11:20:04] INFO: backing off, wait=2s, failures=1 [2015-11-23T11:20:06] INFO: starting new process [2015-11-23T11:20:06] INFO: activeDesktop:Default [2015-11-23T11:20:06] ERROR: could not get session id for process id 4448 [2015-11-23T11:20:06] INFO: starting new process [2015-11-23T11:20:06] INFO: drag and drop enabled At this point the mouse is lost to both client and server. The server keyboard works but after starting an unlock the focus is lost to the password entry so from the server all control is lost. I can remedy this by digging out the keyboard and mouse for the client, unlocking that workstation and then restarting synergy on the client. This brings everything back in line. There is nothing in the event log matching the timestamp on the synergy log events While I do still have problems with 1.7.4 with [alt] and [shift] keys sticking randomly (and still with 1.7.5) this is something I've not seen before

Share this post


Link to post
Share on other sites
To clarify further if I unlock the Server workstation first I can do so correctly but as soon as I move the mouse over to the client screen I lose control again, however if I think take control with the client mouse and switch back to the server mouse I can control both workstations as normal without having to stop and restart the client workstation service. If I leave the client workstation unlocked and only lock the server the result is the same - after unlocking any attempt to switch to the client screen hangs the input until I briefly provided mouse input directly on the client.

Share this post


Link to post
Share on other sites
I'm having the same issue. Any success? The only way I've found to unlock the server (windows 7) is to rdp into the it. Somehow that brings the mouse and keyboard back.

Share this post


Link to post
Share on other sites
At the moment I have no solution but bizarrely it sort of worked this morning - the mouse stopped working but the keyboard was active and I managed to log in (client first). Having tried yet again it seems that if I try to log in on the client (ctrl-alt-pause) immediately without trying anything else the login will work. The mouse does stop but with the keyboard working the login can be performed and as soon as the login progresses the mouse becomes active again and I can unlock the server - from this point it all plays nicely right up until I lock the screens again. It still isn't right but it does mean I don't have to dig out the clients keyboard and mouse in order to unlock both workstations.

Share this post


Link to post
Share on other sites
I have exactly the same configuration (a pair of Win 7 Pro workstations, Synergy 1.7.5) and pretty much the same symptoms. I do have a KVM switch that allows me to switch my mouse and keyboard to the client and restart synergy and work my way out of this condition. Recovery is pretty quick, but I have to do it all too often. I backed out to 1.7.4, which for my configuration is very stable.

Share this post


Link to post
Share on other sites
Having worked around this for a few months now I've hit a real hurdle. A group policy change has reduced the screen time-out (and session lockout) to the point where it is common for one screen to lock without the other. If the screen that locks is the server the fault with 1.7.5 getting mixed up now means I can't access either of my workstations. The only option is to keep a second keyboard and mouse attached so I can dig them out to operate the client workstation. Interaction remains active on the client this way and I can stop the synergy service on the client which then releases control on the server. Restarting the client then allows me to proceed as normal but this is a real PITA to the point where the software is going to be binned. I need to have two sets of keyboard and mouse on my desktop which goes a long way to defeating the object of using this system!

Share this post


Link to post
Share on other sites
The only way I've found to avoid catastrophic situation, is to hit scroll lock when the server station locks, but it's not very easy nor safe.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now