On Thu, 13.04.17 11:58, Martin Wilck ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
