[systemd-devel] [PATCH] dbus: fix --system handling

[Lennart Poettering]

On Tue, 26.10.10 00:44, Michael Biebl (mbiebl at gmail.com) wrote:

> 
> 2010/10/26 Lennart Poettering <lennart at poettering.net>:
> > Note that we do not support booting a real system with systemd on PID !=
> > 1. The primary reason for that is that we need the SIGCHLD signals
> > properly, and we only get those as PID 1. Early systemd versions
> > supported a mode where we didn't rely on those signals. However, we
> > removed that after a while, since I didn't see much benefit in this mode and
> > I was unable and unwilling to keep this mode working and do the
> > necessary testing.
> 
> This leads to an interesting question: How do you intend to support
> running services within a chroot?
> What is your plan for this case?

Hmm, can upstart/sysvinit be run in a chroot env?

I don't think chroot should be taken for a container solution. Because
it's not. If you want a container, use a container, i.e. something
cgroups based such as lxc or so. While I haven't tested that I think it
should mostly work including stuff like like proper SIGCHLD handling. If
things don't fully work, then this is definitely something to fix, in
contrast to weird systemd-in-a-chroot behaviour I think.

I think chroot can be a useful tool for jailing particular services into
subtrees of the fs hierarchy. Either in the way that the service itself
internally chroot()s (which Avahi does, as I think the only service
[still!] which does that by default). Or in a way that this is done
externally, for example via RootDirectory= in systemd service
files. However, I think that the babysitter in that case should live
outside of the jail.

So I think we are well covered here. Or am I missing something?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.