[systemd-devel] Early testing for service enablement

[Lennart Poettering]

On Thu, 13.04.17 12:05, Martin Wilck (mwilck at suse.com) wrote:

> On Thu, 2017-04-13 at 11:45 +0200, Lennart Poettering wrote:
> > On Thu, 13.04.17 08:49, Mantas Mikulėnas (grawity at gmail.com) wrote:
> > 
> > > IIRC, enable/disable/is-enabled are implemented entirely via direct
> > > filesystem access. Other than that, systemctl uses a private socket
> > > when
> > > running as root – it talks DBus but doesn't require dbus-daemon.
> > 
> > Correct, enable/disable/is-enabled can operate without PID 1, but
> > they
> > usually don't unless the tool detects it is being run in a chroot
> > environment.
> > 
> > And yes, systemctl can communicate with PID 1 through a private
> > communication socket that exists as long as PID 1 exists. dbus-daemon
> > is not needed, except when your client is unprivileged.
> 
> If I interpret this answer correctly, you're saying that "systemctl is-
> enabled xyz.service" *should* actually work, even if it's called right
> after PID 1 is started. I'm pretty certain that that wasn't the case
> for me. My client was running from an udev rule and thus not
> unprivileged. That should be considered a bug, then?

Yes, systemctl is-enabled should always work fine regardless if you
run it in early or late boot or even the initrd. However, it will
always just return you the state that applies to its current context,
i.e. inside the initrd it will tell you whether the unit is enabled in
the initrd, and on the host whether it is enabled on the host.

Lennart

-- 
Lennart Poettering, Red Hat