Re: [systemd-devel] Early testing for service enablement

[Lennart Poettering]

On Thu, 13.04.17 11:58, Martin Wilck (mwi...@suse.com) wrote:

> On Thu, 2017-04-13 at 08:49 +, 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
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Early testing for service enablement

[Lennart Poettering]

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

Re: [systemd-devel] Early testing for service enablement

[Martin Wilck]

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?

My tests were done with systemd 228 a while ago.

Martin

-- 
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Early testing for service enablement

[Lennart Poettering]

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.

In recent systemd versions you can even force systemctl to always do
"sytemctl enable/disable/is-enabled" on the client side by setting the
env var SYSTEMCTL_INSTALL_CLIENT_SIDE=1 for it. But this is usually
not necessary nor a good idea, as PID 1 won't notify clients about
changes then, since it doesn't know about them.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Early testing for service enablement

[Martin Wilck]

Hi all,

is there a way to test whether a certain service is enabled (or is
going to be enabled) that would work even very early in the boot
process (in our case from udev rules called in the "udev trigger" phase
both in initrd and after switching root)?

I tried calling "systemctl is-enabled" but it obviously depends on some
services (dbus, I guess) being functional, and didn't provide reliable
results during early boot for us. 

We finally resorted to scanning *.wants directories by ourselves, but
that's of course sub-optimal (poor mans partial implementation of
systemd's service enablement logic). 

Regards
Martin

-- 
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel