catch other signals and unwind
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Medium
|
Unassigned | ||
Breezy |
Triaged
|
Low
|
Unassigned |
Bug Description
Python catches SIGINT and translates it to a KeyboardInterrupt, giving the chance for finally blocks to run.
When running ssh as a subprocess we should get it to ignore these signals so that bzr gets a chance to clean up using the connection.
Jan Hudec suggests
From these, at least HUP, INT, PIPE, TERM, USR1, USR2, PWR (where
defined) and maybe QUIT are likely to occur occasionally and should be
trapped.
PIPE is special; HUP and TERM should be handled this way. USR1, 2 and PWR are rather special and not generally expected.
QUIT conventionally does cause the process to quit fairly promptly; I'm not sure it should be ignored in ssh.
While we're here, perhaps we should use one of them to start the debugger or show the stack?
tags: | added: check-for-breezy |
tags: |
added: ssh removed: check-for-breezy |
Changed in brz: | |
status: | New → Triaged |
importance: | Undecided → Low |
On Wed, 2006-04-26 at 12:01 +0000, Martin Pool wrote:
> Public bug reported:
>
> Affects: bzr (upstream)
> Severity: Normal
> Priority: (none set)
> Status: Unconfirmed
>
>
> Description:
> Python catches SIGINT and translates it to a KeyboardInterrupt, giving
> the chance for finally blocks to run.
>
> When running ssh as a subprocess we should get it to ignore these
> signals so that bzr gets a chance to clean up using the connection.
>
> Jan Hudec suggests
>
> From these, at least HUP, INT, PIPE, TERM, USR1, USR2, PWR (where
> defined) and maybe QUIT are likely to occur occasionally and should be
> trapped.
>
> PIPE is special; HUP and TERM should be handled this way. USR1, 2 and
> PWR are rather special and not generally expected.
>
> QUIT conventionally does cause the process to quit fairly promptly; I'm
> not sure it should be ignored in ssh.
>
> While we're here, perhaps we should use one of them to start the
> debugger or show the stack?
IIRC linux threads uses SIGUSR1 and SIGUSR2 for some purpose. That may
be of historical interest these days with the new pthread
implementation. Either way, I think we should not install handlers for
SIGUSR1 and 2 randomly: sending those signals to us will be an explicit
choice from somewhere.
I think we should only catch exceptions we have an expectation of
recieving - rather than guessing that we can actually do the right thing
when this happens.
HUP is clear - logout with bzr running. INT is ctrl-C. TERM is clear.
PWR - if there is a power failure we may not have time to safely unlock
- but its worth considering. I agree - let QUIT remain unignored: its a
user override signal, and only sent in extremis.
I dont think showing the stack is useful; but invoking pdb is definately
useful.
Rob
-- www.robertcolli ns.net/ keys.txt>.
GPG key available at: <http://