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

Lennart Poettering lennart at poettering.net
Mon Mar 28 13:51:00 PDT 2011


On Wed, 23.03.11 19:55, nerdopolis (bluescreen_avenger at verizon.net) wrote:

> > 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)

No. This is not supported.

Note however that very recent systemd versions have the "systemd-nspawn"
tool which allows you to spawn systemd in a light-weight container. It's
a bit like chroot(1), just on steroids, and much cleaner.

See systemd-nspawn(1) for more information.

> 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.

systemctl currently is already smart enough to not trigger a
configuration reload when "systemctl enable" resp. "systemctl disable"
is run in a chroot() environment. Since on fedora we never start
services from rpm scriptlets this should be enough for us.

If this makes sense we could add an additional restriction that
"systemctl start .." fails with a warning but error code 0 if run in a
chroot. Opinions?

(Currently systemctl start will fail with an error since /run/systemd is
not available in the chroot env, and systemctl hence cannot contact the
init system)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the systemd-devel mailing list