On Tue, 26.10.10 00:44, Michael Biebl (mbi...@gmail.com) wrote: > > 2010/10/26 Lennart Poettering <lenn...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
