On Wed, Dec 29, 2010 at 16:08:48 +0000, Roger Leigh wrote: > On Sun, Dec 26, 2010 at 07:14:54PM +0100, Julien Cristau wrote: > > Package: schroot > > Version: 1.4.16-1 > > Severity: important > > If reproducible, this should probably be severity serious. > > > when i run schroot from two terminals, exiting one kills the other. > > This seems to be a regression from earlier versions, and is bloody > > annoying. > > I've had another report of this occuring (not sure if it was from > yourself), but I wasn't able to reproduce it at the time. > I don't think it was from me.
> I assume this is due to the 15killprocs setup script? If you > add an "exit 0" to the top of this script, does it still occur? > exit 0 at the top of 15killprocs fixes it. > To better understand what's going on here, I really need some more > information about why this is happening, i.e. which commands you > run in each terminal and when. > xterm 1: xterm 2: schroot schroot ^d ^d schroot in xterm 2 stays suspended until I exit the chroot from xterm 1, or, if I don't do that quickly enough, xterm 1 gets: [1]+ Stopped schroot $ fg schroot E: Child terminated by signal 'Killed' $ > Note that if you're running commands in the /same session/ on both > then ending the session will naturally kill all running processes > in that session; this is intended and expected. If you're running > commands in /separate sessions/ and ending one kills the other, > then this is most certainly a major bug. > They're separate sessions, sorry. > 15killprocs works by looking at /proc/"$pid"/root in each process > under /proc, and it kills all those under the chroot mount location > (which should be specific to a schroot session). If I run schroot > with "--vebose --debug=notice" I do see it try to kill the processes > in the other session now, which is really strange. The mount > location is definitely different, but it's specifically killing > processes in the other session. For reasons I'm not yet sure about > the SESSION_ID and CHROOT_MOUNT_LOCATION session names differ; it's > possibly picking up the other session details, but I find that > somewhat unbelievable. > Cheers, Julien
signature.asc
Description: Digital signature