Comment 7 for bug 172392

As an overview of all these bugs:

The client terminates. The ssh client child process is left behind, as is the server process. The server keeps trying to take the lock, and eventually succeeds.

> Even if the client disconnects properly the server process will likely be left running on the other side. As it doesn't have any idea that the client has disconnected.

jml says that this will not happen on Launchpad, where the ssh server will notice that the client has disconnected, and send a sighup to the bzr server process. However, that may not happen with other ssh servers.

To check this, I ran 'ssh localhost sleep 1h', and kill-9'd the client. This left the sleep process running and as far as I can tell with strace, it did not get a sighup. So it looks like just killing the client is not enough to be sure the server will shut down.

One approach would be for the server to just try the lock once, rather than blocking on it, and then come back to the client to say if it was busy. This fixes a few things: the client gets told that it's waiting and can potentially show progress, and the server should rarely take a lock when there's no longer a client wanting it.