On Mon, Jun 07, 2010 at 01:45:47AM +0300, Timo Lindfors wrote: > Some background info: I was trying to help a friend get his new laptop > work with debian lenny: > > When I tried to trick gdm into running Xorg from an unstable chroot I > noticed X would just die with "Caught signal terminated" right after > startup. However, the following wrapper worked:
What command are you using to run gdm? Note that something like this:
schroot -c lenny -u root gdm
will result in an error as you see above. This is because by default
d́́aemons can't run in a chroot. Because the daemon forks and the parent
exits, schroot things the gdm command finished, and so it then cleans
up the chroot and ends the session, killing anything else running inside
the chroot (hence the "Caught signal terminated" error). You may
prevent this like so:
% SESSION=$(schroot -c lenny --begin-session)
% schroot -c $SESSION -u root gdm
...
and then once you are done,
%schroot -c $SESSION --end-session
will tidy up.
However, running daemons is not usually recommended; you might want to
look at more complete virtualisation solutions such as kvm/qemu/Xen for
that.
> #include <unistd.h>
> int main(int argc, char **argv) {
> chroot("/versions/sid");
> chdir("/versions/sid");
> execlp ("/usr/bin/X", "/usr/bin/X", ":0", "-audit", "0","-auth",
> "/var/lib/gdm/:0.Xauth", "-nolisten", "tcp", "vt7", NULL);
> return 0;
> }
>
> It seems that gdm does not tolerate it if the "command=" in gdm.conf
> forks.
What are you using for command= ?
> By avoiding fork with
>
> diff --git a/sbuild/sbuild-session.cc b/sbuild/sbuild-session.cc
> index 220a4fa..ec9f863 100644
> --- a/sbuild/sbuild-session.cc
> +++ b/sbuild/sbuild-session.cc
> @@ -1292,6 +1292,9 @@ session::run_chroot (sbuild::chroot::ptr&
> session_chroot)
> assert(!session_chroot->get_name().empty());
>
> pid_t pid;
> +
> + run_child(session_chroot);
> +
> if ((pid = fork()) == -1)
> {
> throw error(CHILD_FORK, strerror(errno));
>
>
> I was able to make gdm happy. Could you please consider adding this
> behind some --no-fork option?
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.
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.
Regarding the above patch, this actually runs the command twice, the
second time with the usual fork, so isn't usable in this form.
> I would imaging that it is not very
> uncommon to need to run a newer X server and one of the easiest ways
> to do that is to run it from an unstable chroot. (Backports don't even
> have a bug tracking system but insist on a mailing list last time I
> checked).
Backport bug reports are fine in the normal bug tracker.
Hope this was useful.
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.
signature.asc
Description: Digital signature
