Roger Leigh <rle...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
