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

[nerdopolis]

On Monday, October 25, 2010 08:40:50 PM Lennart Poettering wrote:
> 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

Hi.

so will it be possible to run a seperate systemd outside of a chroot for a 
chroot? ( bonus if not as PID 1)

My concern is that currently with Upstart, (I don't know about other package 
managers) and dpkg in a chroot, some packages will install, and then try to 
start its service automatially (by connecting to Upstart). Since it can't 
connect, the package reports failure to install, and dpkg stops dead in its 
tracks, and it won't continue.

I tried chrooting into a system that uses systemd, and starting a systemd 
service and noticed that it reports it can't connect. If a package attempted 
to start a service like that in chroot, it probably would fail.

This mostly will affect people trying to install some packages on an offline 
system.

Are my arguments valid?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110323/7fe3a4dd/attachment.htm>