Bug#679499: [buildd-tools-devel] Bug#679499: Bug#679499: schroot: suspend fails from chroot
On Mon, Dec 10, 2012 at 07:15:36PM +, Toby Speight wrote: 0 In article 20121014231616.gn5...@codelibre.net, 0 Roger Leigh URL:mailto:rle...@codelibre.net (Roger) wrote: Roger I'll try trapping SIGCONT/SIGSTOP, and then raise the same signal Roger on ourselves. However, this could open a horrible can of worms, Roger e.g. if you send SIGCONT to bash while schroot is stopped. I've tried that scenario, and the child bash does continue okay when given SIGCONT, and resuming schroot gets me back correctly. Weird things happen if the child exits when schroot is not in the foreground, though - it seems that the parent (of schroot) is told to stop. In other words, if we do something like: Many thanks for the patch. I'm afraid I'm a little busy to look at it in detail right now; maybe while I'm home for Christmas. I do have a lurking suspicion that the odd corner cases are why ssh doesn't implement this; it's safer to not try to deal with the problem. After being bitten by trying to be too clever in the past with job control (in sbuild), I'm somewhat wary of changing things here unless we can be absolutely certain they won't cause problems. However, in general your patch looks reasonable; if it doesn't solve all the problems, it's at least on the right track. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679499: [buildd-tools-devel] Bug#679499: Bug#679499: schroot: suspend fails from chroot
0 In article 20121210203903.gi14...@codelibre.net, 0 Roger Leigh URL:mailto:rle...@codelibre.net (Roger) wrote: Roger Many thanks for the patch. I'm afraid I'm a little busy to look Roger at it in detail right now; maybe while I'm home for Christmas. Roger Roger I do have a lurking suspicion that the odd corner cases are why Roger ssh doesn't implement this; it's safer to not try to deal with Roger the problem. Yes, or at least make it something that must be explicitly requested (command line or config file). I'm certainly not pressing for such a thing to be rushed into schroot, and the patch is mainly just a straw-man to get more eyes on this. Thanks again for responding; I may be out of contact a fair bit over the Christmas and New Year period, but will respond to emails after that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679499: [buildd-tools-devel] Bug#679499: schroot: suspend fails from chroot
0 In article 20121014231616.gn5...@codelibre.net,
0 Roger Leigh URL:mailto:rle...@codelibre.net (Roger) wrote:
Roger This is quite an interesting problem, and will need a bit more
Roger investigation before I find a solution.
I fully expected that! :-)
I have however just tried a bit of experimentation, which does basically
what you suggest here:
Roger I'll try trapping SIGCONT/SIGSTOP, and then raise the same signal
Roger on ourselves. However, this could open a horrible can of worms,
Roger e.g. if you send SIGCONT to bash while schroot is stopped.
I've tried that scenario, and the child bash does continue okay when
given SIGCONT, and resuming schroot gets me back correctly. Weird
things happen if the child exits when schroot is not in the foreground,
though - it seems that the parent (of schroot) is told to stop. In
other words, if we do something like:
/
| ~$ schroot -d / -c child -u root
| /# suspend; exit
|
| [1]+ Stopped schroot/schroot -d / -c child -u root
| ~$ bg
| [1]+ schroot/schroot -d / -c child -u root
\
I get
/
| ~$ exit
| exit
\
without asking for it. Since all my other tests are successful and I
don't know what causes the above, I present my patch below, in the hope
that someone can identify what's needed. Admittedly, typing suspend;
exit (or even suspend; exec command) seems a fairly oddball case.
If I use 'fg' rather than 'bg', it works; also if I start schroot
backgrounded, with a command such as 'schroot -- sleep 3 ' or
'schroot -- bash -c sleep 3 '.
If I use 'schroot -- bash -i -c sleep 3 ', I get some strange
behaviour. It stops itself, and if I immediately type 'fg' I get the
unasked-for exit (which can be prevented if you get bash to give
There are stopped jobs. message, by having another background
process). A second 'fg' gets in, and the sleep runs. If I first
just press enter, the parent notices schroot stop, but I still need
to 'fg' twice to get in.
Here's the patch I've been trying:
diff -u -x '*~' schroot-1.6.4/sbuild/sbuild-session.cc schroot-new/sbuild/sbuild-session.cc
--- schroot-1.6.4/sbuild/sbuild-session.cc 2012-10-27 23:39:05.0 +0100
+++ schroot-new/sbuild/sbuild-session.cc 2012-12-10 18:54:56.421884095 +
@@ -1431,7 +1431,7 @@
child_killed = true;
}
- if (waitpid(pid, status, 0) == -1)
+ if (waitpid(pid, status, WUNTRACED) == -1)
{
if (errno == EINTR (sighup_called || sigterm_called || sigint_called))
continue; // Kill child and wait again.
@@ -1450,6 +1450,16 @@
}
// No need to handle the SIGINT case here; it is handled
// correctly below
+ else if (WIFSTOPPED(status))
+{
+ siginfo_t info;
+ int stopsig = WSTOPSIG(status); // one of SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU
+ raise(stopsig);
+ // time passes ... when we come back, attempt to wake the child
+ // (which may now be a zombie, but that's fine):
+ kill(pid, SIGCONT);
+ continue;
+}
else
break;
}
Bug#679499: [buildd-tools-devel] Bug#679499: schroot: suspend fails from chroot
On Fri, Jun 29, 2012 at 09:00:31AM +0100, Toby Speight wrote: If I use plain 'chroot' to access a working system, with SHELL=/bin/bash, I can type 'suspend' into bash, and get back to my parent shell. If I use 'schroot' to do the same, then 'suspend' just hangs until I go to another terminal and 'kill -CONT' the bash process. I would like schroot to behave the same as plain chroot. I appreciate it might not be trivial (chroot doesn't have to do anything special, as it simply exec()s the required command, whereas schroot would have to detect its child stopping and do the same to itself - I've no idea how to do that). This is quite an interesting problem, and will need a bit more investigation before I find a solution. bash sets up its own process group on startup. When you call suspend, it signals the whole process group to stop. But since schroot isn't in the same group, it's not suspended. Ideally, you would only run a login shell with schroot, but we're not in an ideal world ;) schroot uses PAM, and basically treats commands being run in the chroot as though they were run as a separate login, e.g. equivalent to running ssh or sudo. That said, it should be possible to do this. schroot itself isn't doing anything special by starting any new sessions with setsid or setpgid, and itself works perfectly well with job control. Try running any command other than a shell (e.g. more or anything you like, or run schroot as part of a pipeline e.g. schroot ls -l / | less) and you'll see that it all works fine in that you can press C-Z and it all suspends properly. So to support suspending a shell within ourselves, I'm not sure what is best to do here. I'll try trapping SIGCONT/SIGSTOP, and then raise the same signal on ourselves. However, this could open a horrible can of worms, e.g. if you send SIGCONT to bash while schroot is stopped. We won't be restarted ourselves then, and bash might then immediately get SIGTTOU/IN etc. I also don't want to break schroot running correctly in the normal/pipeline cases shown above. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679499: [buildd-tools-devel] Bug#679499: Bug#679499: schroot: suspend fails from chroot
On Mon, Oct 15, 2012 at 12:16:16AM +0100, Roger Leigh wrote: This is quite an interesting problem, and will need a bit more investigation before I find a solution. bash sets up its own process group on startup. When you call suspend, it signals the whole process group to stop. But since schroot isn't in the same group, it's not suspended. Ideally, you would only run a login shell with schroot, but we're not in an ideal world ;) Just as another datapoint: Try running ssh localhost -t bash and then try suspend in the shell. You'll notice that it behaves identically to schroot. The -t is to allocate a TTY, otherwise you don't get any shell job control (or suspend). It would be interesting to know how any other similar tools behave. su/sudo/chroot just exec their command after setting things up, so there isn't a parent process waiting for a child. So it's limited to programs which fork a shell and wait for it, like schroot and ssh. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679499: schroot: suspend fails from chroot
Package: schroot
Version: 1.5.4-1
Severity: normal
If I use plain 'chroot' to access a working system, with
SHELL=/bin/bash, I can type 'suspend' into bash, and get back to my
parent shell.
If I use 'schroot' to do the same, then 'suspend' just hangs until I
go to another terminal and 'kill -CONT' the bash process.
I would like schroot to behave the same as plain chroot. I appreciate
it might not be trivial (chroot doesn't have to do anything special, as
it simply exec()s the required command, whereas schroot would have to
detect its child stopping and do the same to itself - I've no idea how
to do that).
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (900, 'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
Kernel: Linux 3.2.9-balti (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages schroot depends on:
ii libboost-filesystem1.49.0 1.49.0-3
ii libboost-iostreams1.49.01.49.0-3
ii libboost-program-options1.49.0 1.49.0-3
ii libboost-regex1.49.01.49.0-3
ii libboost-system1.49.0 1.49.0-3
ii libc6 2.13-33
ii libgcc1 1:4.7.0-8
ii liblockdev1 1.0.3-1.5
ii libpam0g1.1.3-7.1
ii libstdc++6 4.7.0-8
ii libuuid12.20.1-5.1
ii schroot-common 1.5.4-1
schroot recommends no packages.
Versions of packages schroot suggests:
pn aufs-modules | unionfs-modules none
pn btrfs-tools none
ii debootstrap 1.0.41
pn lvm2none
ii qemu-user-static1.1.0+dfsg-1
-- Configuration Files:
/etc/schroot/setup.d/15binfmt changed:
set -e
. $SETUP_DATA_DIR/common-data
. $SETUP_DATA_DIR/common-functions
. $SETUP_DATA_DIR/common-config
if [ $STAGE != setup-start ] \
[ $STAGE != setup-stop ] \
[ $STAGE != setup-recover ]; then
exit 0
elif ! which update-binfmts /dev/null; then
info Missing update-binfmts; not enabling binfmt support
exit 0
fi
shell=${CHROOT_PATH}/bin/sh
for emulator in $(update-binfmts --find $shell); do
dst=${CHROOT_PATH}$emulator
if [ ! -e $emulator ]; then
info Missing emulator: $emulator; not enabling binfmt support
else
[ -e $dst ] || touch $dst
mount --bind $emulator $dst
mount -o remount,ro,bind $dst
fi
done
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
