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
