[buildd-tools-devel] Bug#584831: Bug#584831: schroot: please add an option to avoid fork()

[Timo Lindfors]

Roger Leigh <rleigh at codelibre.net> writes:
> What command are you using to run gdm?

gdm is started by init normally. I am only running Xorg from the chroot.

> What are you using for command= ?

/etc/gdm/gdm.conf has

[server-Standard]
command=/usr/local/bin/sid-X

where /usr/local/bin/sid-X contains

#!/bin/sh
/usr/bin/schroot -c sid2 -p -q -- /usr/bin/X "$@"

and is executable.

>   schroot -c lenny -u root gdm

I'm sorry if I was unclear but this is not what I intended to do. If I
run gdm from chroot then also window managers and things like that will
get started from the chroot? I only want to run Xorg itself from
unstable to keep my system otherwise as stable as possible :-)

> schroot runs by creating, using and removing "sessions".  The reason for
> forking is so that the user command/shell runs in the child and the
> parent waits for it to complete so that it can clean up after.
> If the fork is removed, then schroot is no longer running and cleanup
> will not occur.  I'm open to suggetions for how to change things, but
> this is at the moment fundamentally incompatible with the architecture
> of schroot.

Yes I am aware of that. However, I am only suggesting this as an extra
option, is cleanup always necessary? I am not using run-*-scripts in
schroot.conf. With

[sid2]
description=Debian sid2 (unstable)
location=/local/chroot/sid2
aliases=unstable2
users=root,lindi

running the command

strace -o s -s4096 -f sid2 date

as root does not seem to do any real cleanup, it only sends a line to
syslog:

5685  <... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 5686
5685  --- SIGCHLD (Child exited) @ 0 (0) ---
5685  getuid32()                        = 0
5685  time(NULL)                        = 1275892257
5685  stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
5685  send(4, "<86>Jun  7 09:30:57 schroot[5685]: pam_unix(schroot:session): session closed for user root"..., 90,
MSG_NOSIGNAL) = 90
5685  rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0
5685  rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0
5685  munmap(0xb6e90000, 6100)          = 0
5685  munmap(0xb6e13000, 100032)        = 0
5685  munmap(0xb6e2c000, 101276)        = 0
5685  munmap(0xb6de1000, 201052)        = 0
5685  close(4)                          = 0
5685  close(3)                          = 0
5685  munmap(0xb7fde000, 4096)          = 0
5685  exit_group(0)                     = ?
5684  <... waitpid resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0) = 5685
5684  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
5684  --- SIGCHLD (Child exited) @ 0 (0) ---
5684  waitpid(-1, 0xbff17dd8, WNOHANG)  = -1 ECHILD (No child processes)
5684  sigreturn()                       = ? (mask now [])
5684  rt_sigaction(SIGINT, {SIG_DFL}, {0x807ef30, [], 0}, 8) = 0
5684  rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
5684  read(255, ""..., 40)              = 0
5684  exit_group(0)                     = ?

> I'm also unsure /why/ it's having any effect.  I can understand the
> daemon running in the chroot forking being a problem; schroot forking
> internally shouldn't be interfering with anything--it's just a detail
> and shell job control etc. shouldn't be affected.  Some more details
> about what exactly the problem is and why this change corrects that
> would be appreciated.

I managed to reproduce the problem on my desktop system. Xorg is started 

/usr/bin/schroot -c sid2 -p -q -- /usr/bin/X :0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt8
 \_ /usr/bin/X :0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt8

just fine but after about 10 seconds gdm starts to complain:

/usr/sbin/gdm
 \_ /usr/sbin/gdm
     \_ /usr/lib/gdm/gdmopen -l /bin/sh -c /usr/bin/whiptail --yesno  'There already appears to be an X s
         \_ /usr/bin/whiptail --yesno There already appears to be an X  server running on display :0.  Sh

I do not know how exactly gdm detects the extra fork. xdm seems to work
with schroot so gdm is definitely doing some extra checks here.

> Regarding the above patch, this actually runs the command twice, the
> second time with the usual fork, so isn't usable in this form.

Yes the patch was just a rudimentary proof of concept.

> Backport bug reports are fine in the normal bug tracker.

Great!


best regards,
Timo Lindfors