multipathd runs by default on Ubuntu Server, even where that doesn't make sense

vms can certainly use multipath devices; why would we want to disable it? is this only to speed up boot slightly?

Just a quick reminder.. we already made open-iscsi socket oriented and that is also to be done with multipath-tools (I think I've done last 2 merges for both). I did not want to go for a full review on multipath-tools this last cycle (but did for open-iscsi). FYIO.

The !container is because multipath tools talk with systemd-udev and that is only supported in the host (just like iscsid does). That is why there might be a condition not to start on container systems, just because the container might not be able to control udev/dm within kernel (but, again, that was for me to do this cycle... will have to do next one, after my current assignment, or someone else can do it).

Hi and thanks for chiming in.

I probably underestimated how often multipath is used in VMs, but I still think that the vast majority of the cloud instances out there have no use for it. However I see your point, what we need is to enable socket based activation for multipathd, as Rafael proposed. I'm retitling this bug accordingly.

To add another perspective here: because this is seeded in ubuntu-server we wind up running multipathd on our Pi server images. These run on big fat 8GB Pi 4s (where presumably no-one really notices), but also 512MB Pi Zero 2s where the 25MB of RAM that multipathd consumes represents 5% of all the RAM on the system (and typically about 10% of the available RAM at runtime). Given there's little prospect of attaching multipath hardware to such a machine this seems somewhat wasteful :)

Socket activation would certainly help in this use-case (though I'm not sure it's actually that useful for the PC use-case as it would imply multipathd wouldn't run until the CLI was used?), but for the time being I've recommended Pi server users add multipath=off to their kernel config on the smaller Pis to save a bit of memory.

I think this bug needs to be a little more generic then. The fundamental issue here is that multipathd runs by default in places where we don't expect it to.

Taking a quick glance at this, socket activation wouldn't be enough since that's only used for CLI access. We'd want multipathd running on a system that's using multipath I think, even when nobody has touched the CLI. So some kind of activation based on systemd/udev might make sense instead.

It might also be worth considering making the seed a recommends so that Pi users can remove the package.

Thanks, converted to an item candidate to finally find the time to work on this.