[systemd-devel] Early testing for service enablement

Lennart Poettering lennart at poettering.net
Mon Apr 17 09:46:41 UTC 2017


On Thu, 13.04.17 11:58, Martin Wilck (mwilck at suse.com) wrote:

> On Thu, 2017-04-13 at 08:49 +0000, Mantas Mikulėnas 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.
> 
> 
> > A bigger problem is that initramfs can't know much about the main
> > system due to having a separate /etc, unless maybe you run `systemctl
> > --root=...`
> 
> This is not a problem for us because in initramfs, we only care whether
> the service is enabled in initramfs itself.
> 
> > Could you elaborate on why you find this checking necessary in the
> > first place? Do your udev rules run some weird stuff?
> 
> It's about multipath. In the udev rule that checks whether or not a
> given device should be treated as a multipath device path, we need to
> figure out whether multipathd.service is enabled. We want to to that
> without connecting to multipathd.socket at that time in the boot
> process, because that would fire up multipathd, and there's strong
> evidence that multipath-enabled systems boot more stably if multipathd
> is started later (after udev settle). Therefore the idea was to obtain
> the information from systemd ("will multipathd.service be started later
> in the boot process?").

That appears questionnable to me. Synchronously requesting data from
other services from inside an udev rule like that appears highly
problematic to me, in particular if you sometimes do it and sometimes
not, as that makes things underterministic.

Also: instead of checking whether a service unit is enabled before
contacting a specific socket, please make sure that the socket unit is
only enabled if the service is enabled too (i.e. via Also= in the
[Install] section of the service), so that you can directly talk to
the socket, and if the service is not enabled (and hence the socket
either) you will just get an ENOENT/ECONNREFUSED back...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list