multipathd/socket: start conditions not aligned with service unit, funky result

[lucab]

Right now the service unit multipathd.service has several start conditions that the socket unit multipathd.socket does not have. It would be good to align the set of conditions across the two units.

The current diff is:

> ConditionKernelCommandLine=!nompath
> ConditionKernelCommandLine=!multipath=off
> ConditionVirtualization=!container

This means that if one of the conditions is not met (e.g. kargs contains nompath), a client could trigger the socket unit to start, then enter a retry loop, and eventually be marked as failed. The socket unit has not other possible outcome than ending up in a failed state, because it is indeed impossible to start the related service.

As a real example, a random client command like multipathd show daemon will send the multipathd.socket unit into this failed state:

* multipathd.socket - multipathd control socket
     Loaded: loaded (/usr/lib/systemd/system/multipathd.socket; enabled; vendor preset: disabled)
     Active: failed (Result: trigger-limit-hit) since Tue 2021-09-21 14:37:45 UTC; 17s ago
   Triggers: * multipathd.service
     Listen: @/org/kernel/linux/storage/multipathd (Stream)

Sep 21 14:37:45 coreos-scratch systemd[1]: multipathd.socket: Trigger limit hit, refusing further activation.
Sep 21 14:37:45 coreos-scratch systemd[1]: multipathd.socket: Failed with result 'trigger-limit-hit'.

This happens because the unit is trying really hard to activate the service unit and forward the client request to it. However, multipathd.service is instead in the following state, where it will (correctly) never manage to actually start (despite all the retries):

* multipathd.service - Device-Mapper Multipath Device Controller
     Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Tue 2021-09-21 14:33:08 UTC; 4min 54s ago
TriggeredBy: x multipathd.socket
  Condition: start condition failed at Tue 2021-09-21 14:37:45 UTC; 17s ago
             `- ConditionKernelCommandLine=!nompath was not met
   Main PID: 476 (code=exited, status=0/SUCCESS)
        CPU: 21ms

Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.
Sep 21 14:37:45 coreos-scratch systemd[1]: Condition check resulted in Device-Mapper Multipath Device Controller being skipped.

[mwilck]

We can change this in multipath-tools, but it sounds like a systemd issue to me. The same would apply for any socket-activated unit. I can see no documented requirement that the conditions in socket units and their associated service units must be equal.

[lucab]

PR at #16.

Yes I think it's a bit of an unfortunate corner-case of systemd dependency graph, but I believe this comes from the deliberate decision of keeping unit settings as self-contained as possible (i.e. not infecting other units).