"bzr break-lock bzr+ssh://bazaar.launchpad.net/..." fails to break a lock

[Andrew Bennetts]

It appears that "bzr break-lock bzr+ssh://bazaar.launchpad.net/..." fails to actually break locks.

See comments of bug #125420 for some examples. Also reported on IRC and possibly the mailing list IIRC.

The workaround is to use sftp:// instead of bzr+ssh:// with break-lock.

[Michael Hudson-Doyle (mwhudson)]

I don't think this is a problem with the supermirror specifically. I can confuse myself rotten just playing around pushing to bzr+ssh://localhost/tmp/whatever (and locking it by just python2.4 -c 'from bzrlib import branch; branch.Branch.open("bzr+ssh://localhost/tmp/whatever").lock_write()').

I think the problem could be that there are bzr serve processes hanging around after the client has disconnected, i.e. I think this could be a dupe of bug #141172.

[Michael Hudson-Doyle (mwhudson)]

Actually I think this is related to the just filed bug #172392, not 141172.

[Jonathan Lange (jml)]

This has been observed on vanilla smartservers, so it's not a Launchpad bug.

[Jonathan Lange (jml)]

Andrew has said that he will look at this on Monday. We'd really like this fixed for the 1.0 / 1.12 release.

[Andrew Bennetts (spiv)]

I'll try to fix this today, hopefully we can get it into bzr 1.0.

[Andrew Bennetts (spiv)]

Oops, target for 1.0rc3 rather than final!

[Martin Pool (mbp)]

not for 1.0

[Paul Tagliamonte (paultag)]

bug still present in 1.0.0

[C.Kontros (coryisatm)]

Still present in 1.2.0.candidate.1 (hardy). This is really unacceptable and unfair to people managing projects with LP/BZR. This has been open for 4 months.

[John A Meinel (jameinel)]

I thought the fix was to change the timeout in the server process. Which means this is actually a launchpad-bazaar bug, not a bzr client bug.

Specifically in bzr-1.1 this was introduced:
        old_lockdir_timeout = lockdir._DEFAULT_TIMEOUT_SECONDS
        try:
            ui.ui_factory = ui.SilentUIFactory()
            lockdir._DEFAULT_TIMEOUT_SECONDS = 0
            smart_server.serve()
        finally:
            ui.ui_factory = old_factory
            lockdir._DEFAULT_TIMEOUT_SECONDS = old_lockdir_timeout

Setting the timeout to 0 seconds means that the bzr service will not hang waiting for the lock, but fail immediately. (This only needs to be present on the server, not on the client).

So marking it fixed in bzr, but open in launchpad-bazaar.

[Jonathan Lange (jml)]

I could have sworn this was fixed...

[Jonathan Lange (jml)]

It turns out that it *is* fixed, sort of.

I'm guessing that you are doing 'bzr push', seeing the lock message and then hitting Ctrl-C, because that's the only way I could reproduce this big. When you do that, Bazaar leaves the SSH process lying around still connected to Launchpad (see bug 141172 and bug 172392).

This means that running 'bzr break-lock' actually does break the lock. Unfortunately, the ssh process immediately re-acquires the lock, so when you try to push again, it looks as if break-lock didn't work.

This behaviour is undesirable and work to fix it is being tracked in the bugs I mentioned earlier. I'll have a chat to the Bazaar guys to see if we can get it fixed soon.

[John A Meinel (jameinel)]

So.... I believe when we spawn ssh we explicitly first call something to ignore SIGINT before we spawn the process.

I believe we did that originally so that when someone does ^C we would have a chance to clean up before we exited out of our process.

So the question is, how can we have both? Have the subprocess not die until we have done everything we can. We can't just grab the SIGINT and queue it up to be raised later. Because if we don't set the subprocess to ignore it, then it dies right away. If we do set it to ignore it, then there is no way we can send it SIGINT when we are ready.

Anyway, the quick fix would be to do:
=== modified file 'bzrlib/transport/ssh.py'
--- bzrlib/transport/ssh.py 2008-02-08 18:36:35 +0000
+++ bzrlib/transport/ssh.py 2008-03-14 15:19:29 +0000
@@ -587,8 +587,7 @@
         # Running it in a separate process group is not good because then it
         # can't get non-echoed input of a password or passphrase.
         # <https://launchpad.net/products/bzr/+bug/40508>
- return {'preexec_fn': _ignore_sigint,
- 'close_fds': True,
+ return {'close_fds': True,
                 }

But I think that will end up causing more locks to be left around.