fix(multipath): enable service but disable socket

[cthbleachbit]

Changes

This fixes a hang in the cleanup hook: running multipath binary triggers activation of multipathd.service after it is (and must remain) stopped as dracut prepares to switch root in initrd-cleanup.service.

An earlier fix from PR #2010 was based on an old systemd behavior where missing socket will prevent the service from being enabled. This does not seem to be the case anymore. For completeness, I'm disabling the socket alone after enabling service.

At the end of the day we should probably remove Also=multipathd.socket from multipathd.service and upsteam this change. The whole point of having a socket enabled separately from the service is that systemd can start the service as-needed. Binding enable/disable status together would not be very sane.

Checklist

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

Fixes #2289, #2175

[mwilck]

See opensvc/multipath-tools#65

I think we should get rid of the entire multipathd-needshutdown logic. It isn't needed any more.

[mwilck]

I don't know why #2210 was made because I wasn't involved, and there was no bug report linked.
I suppose the issue was related to udev; when multipath is running from udev rules it might try to access the socket.
But the startup sequence for multipathd has been changed such that it starts before udev ist starting, so that should not be a problem any more.

I don't think we should rely on socket activation for multipathd in the initrd.

[mwilck]

I suppose the issue was related to udev

That can't be the case; multipath -u and multipath -U as run from udev rules don't access the socket.
Wrong. multipath -u must access the socket because if multipathd isn't running, no path will be considered valid.

Another thing worth trying here would be to run multipath with the -D option. This avoids that multipath tries to connect to the multipathd socket.

[cthbleachbit]

I don't think we should rely on socket activation for multipathd in the initrd.

Absolutely not. The only reason that the socket got involved is due to it declared in Also= from the service. This cause systemd to sync status to the socket unit when enabling/disabling the service. On a hindsight the service probablty should not even have this Also=multipathd.socket declared.

The -D option doesn't seem to be documented in the manual nor in the command help prints as of multipath-tools 0.9.3...

[mwilck]

I don't think we should rely on socket activation for multipathd in the initrd.

Absolutely not. The only reason that the socket got involved is due to it declared in Also= from the service. This cause systemd to sync status to the socket unit when enabling/disabling the service. On a hindsight the service probablty should not even have this Also=multipathd.socket declared.

Well, as I said above, either multipathd must be running, or socket activation must be enabled, otherwise multipath activation in the initrd will fail. The best idea would be to start multipathd early in the intird.

The Also= line has been added 10y ago and never been questioned. You are right that Also= is wrong here: If multipathd is enabled, enabling the socket unit makes little sense. Likewise, the socket shouldn't be disabled just because someone disables the service. If socket activation is desired, the socket should be enabled and service should be disabled.

The -D option doesn't seem to be documented in the manual nor in the command help prints as of multipath-tools 0.9.3...

Right. It's an undocumented feature :-) . It isn't meant for end users. But it might be useful for dracut. It would not make a difference for multipath -u though (see above). I need to double-check this again.

[cthbleachbit]

either multipathd must be running, or socket activation must be enabled

So dracut enables multipathd.service - fine on its own. Enabling service enables multipathd.socket as well because the service has Also=multipathd.socket.

[mwilck]

either multipathd must be running, or socket activation must be enabled

So dracut enables multipathd.service - fine on its own. Enabling service enables multipathd.socket as well because the service has Also=multipathd.socket.

Understood. The Also= is wrong indeed.

[mwilck]

Just sent a patch to [email protected] for the upstream service unit.

[mwilck]

What I said about -D above was wrong, too, sorry.

-D only has an effect for map creation (multipath) or flushing (multipath -f $map, multiapth -F).
But the dracut scripts in question only run multipath -l, which doesn't connect to the socket.

So it remains unclear to me why the socket is activated.

[jiayi0118]

This patch works in my system.

LGTM

[aafeijoo-suse]

IIUC, if Martin's patch removing the Also= from multipathd.service is accepted, I'd just simply revert 02e646f

[cthbleachbit]

I'd guess that dracut needs to account for older versions of mp-tools.

Maybe I should just revert #2010 and remove Also= for the copy of multipathd.service in dracut's repo as well.

[mwilck]

IIUC, if Martin's patch removing the Also= from multipathd.service is accepted, I'd just simply revert 02e646f

It has got positive review and is scheduled to be merged with opensvc/multipath-tools#64

[cthbleachbit]

Following upstream. My old fix reverted and Also= line removed.

[LaszloGombos]

LGTM

[mwilck]

FTR: I had a similar discussion about a different unit recently, shedding some more light on the issue.2

At the end of the day we should probably remove Also=multipathd.socket from multipathd.service and upsteam this change. The whole point of having a socket enabled separately from the service is that systemd can start the service as-needed. Binding enable/disable status together would not be very sane.

Using Also=$X.socket in a service unit $X makes sense if and only if the service unit has no [Install] section. In that case, systemctl enable $X.service will install the socket unit instead of the service unit, which makes sense for a daemon that has no purpose except serving the socket. But multipathd serves many more purposes, and therefore using Also=multipathd.socket is wrong.

[aafeijoo-suse]

Using Also=$X.socket in a service unit $X makes sense if and only if the service unit has no [Install] section. In that case, systemctl enable $X.service will install the socket unit instead of the service unit, which makes sense for a daemon that has no purpose except serving the socket. But multipathd serves many more purposes, and therefore using Also=multipathd.socket is wrong.

Thanks for this background explanation Martin, sometimes systemd is too tricky...