[dm-devel] multipath-0.5.0 still provides broken udev rules

[Benjamin Marzinski]

On Tue, Apr 26, 2016 at 07:53:48AM +0200, Hannes Reinecke wrote:
> On 04/25/2016 10:14 PM, Xose Vazquez Perez wrote:
> > On 04/25/2016 02:56 PM, Christophe Varoqui wrote:
> > 
> >> Those example udev rules are indeed unmaintained and should be
> >> removed not to confuse distributors.
> >>
> >> Distributors can't be asked to agree on a common udev ruleset.
> >> Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example ?
> > 
> > Fine with me.
> > 
> > Btw, are these relevant ?

For all that I didn't comment on, I feel the same way as Hannes.

> > getuid/usb_id
> Huh? What is that doing there?
> It should really have been moved to the udev package ...
> 
> > kpartx/kpartx_id
> > kpartx/kpartx.rules
> See above. Yes, they are relevant (at least for us)

Like I said, Red Hat doesn't use them. I'll post our multipath.rules
shortly.

> > multipath/01_udev
> > multipath/02_multipath
> Not used anymore with systemd/dracut
> 
> > multipath/11-dm-mpath.rules
> Yep. Absolutely required.
> 
> > multipath.conf.annotated
> > multipath.conf.defaults
> > multipath.conf.synthetic
> Actually, I never saw the need for those.
> Can we at least have them merged?

I don't think they are being kept up to date anymore.  The 'defaults'
information can be gotten from a running system, and it includes the
changes from the config files, so it's much more useful. I have no idea
what people would use 'synthetic' for besides an example of what a
config would look like. And the 'annotated' information is all in the
multipath.conf manpage. Red Hat doesn't ship these files anymore. I'd be
happy to see them go.
 
> > multipathd/multipathd.init.debian
> > multipathd/multipathd.init.redhat
> > multipathd/multipathd.init.suse
> Old init scripts; doubtful value.
> 
> > multipathd/multipathd.service
> > multipathd/multipathd.socket
> systemd service definitions. Yes, required.

Red Hat has a slightly different multipathd.service file, and we don't
ship the socket file.  Since multipathd should always be running, I
don't really see the need. Also, if you start multipathd manually
(instead of through udev) this causes problems with multipathd not
getting messages.

For those interested, here's a diff of our multipath.service

diff --git a/multipathd/multipathd.service
b/multipathd/multipathd.service
index d5f8606..1e5dfab 100644
--- a/multipathd/multipathd.service
+++ b/multipathd/multipathd.service
@@ -2,9 +2,10 @@
 Description=Device-Mapper Multipath Device Controller
 Before=iscsi.service iscsid.service lvm2-activation-early.service
 Before=local-fs-pre.target
-After=multipathd.socket
+ConditionPathExists=/etc/multipath.conf
+ConditionKernelCommandLine=!nompath
 DefaultDependencies=no
-Wants=local-fs-pre.target multipathd.socket blk-availability.service
+Wants=local-fs-pre.target blk-availability.service
 Conflicts=shutdown.target
 
 [Service]
@@ -12,9 +13,9 @@ Type=notify
 NotifyAccess=main
 LimitCORE=infinity
 ExecStartPre=/sbin/modprobe dm-multipath
+ExecStartPre=-/sbin/multipath -A
 ExecStart=/sbin/multipathd -d -s
 ExecReload=/sbin/multipathd reconfigure
 
 [Install]
 WantedBy=sysinit.target
-Also=multipathd.socket


Aside from dropping the socket, it checks that /etc/multipath.conf
exists, and that the kernel wasn't started with "nompath". Also it runs
"multipath -A" this reads the kernel commandline from /proc/cmdline, and
adds any wwids listed as part of any mpath.wwid=<wwid> parameters.
Hannes NACKed this patch, so the option isn't present upsteam.

 
> > multipath/multipath.init.suse
> Old init script; not used anymore.
> 
> > multipath/multipath.rules
> Yep. used for udev.
> 
> > multipath-tools.spec.in
> > 
> Well; due to our buildservice we have to keep a separate spec file
> anyway. So ATM we don't use it.
> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		   Teamlead Storage & Networking
> hare at suse.de			               +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> HRB 21284 (AG Nürnberg)