Comment 8 for bug 2000186

A few observations:

- invoke-rc.d shouldn't even be part of the equation here. I would consider this a bug in the Ubuntu package (or in the packaging helpers, generally) - this is a systemd system, /etc/init.d/multipath-tools should be shadowed by /lib/systemd/system/multipath-tools.service which is a symlink to multipathd.service, so calling invoke-rc.d on an Ubuntu system at all is wrong because in the *best case* it's duplicating the systemd unit handling already present via dh_systemd_start.
- maintainer scripts *should* error out if a service that was running fails to restart after an upgrade, because all the other options for error handling are worse. However, if a system was booted just fine and a given service was not running before upgrade, failing to start it shouldn't /necessarily/ result in the maintainer script failing. This is *probably* something we can have better semantics for with systemd than we did with init scripts, but I don't know that such a thing is implemented currently.
- multipath-tools should be installed as part of the default Ubuntu Server system (via the ubuntu-server metapackage), for the same reason that cryptsetup and lvm2 and mdadm and sundry other tools are installed by default even on systems that aren't using them - because hardware can change out from under an install, and you shouldn't need to install extra software when that happens.
- however, multipathd should *not* be running by default on systems where it's not needed, a pet peeve of mine (and many others). Memory usage on a typical (kinetic, in this case) VM:

1649760 root 20 0 1549644 112808 19324 S 0.0 2.8 58:55.08 lxd
 455051 root 20 0 844712 40964 26352 S 3.6 1.0 3949:52 jujud
3295101 1000000 20 0 734588 30796 8168 S 0.0 0.8 0:42.32 snapd
3287494 root 20 0 734588 30304 8792 S 0.0 0.8 1:03.02 snapd
1080861 root rt 0 290116 25764 7464 S 0.0 0.6 12:43.34 multipa+

consuming memory, consuming CPU time, doing nothing useful.

Ideally multipathd would be installed, but would only start if it was detected at runtime that it was needed. And then, as a side effect, it wouldn't be failing to restart on upgrade because it legitimately shouldn't be running.

It is non-trivial to get to that ideal state from where the package is today, but that *should* be the goal.