On Thu, 13.04.17 12:05, Martin Wilck (mwi...@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 (graw...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel