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

[Hannes Reinecke]

On 04/28/2016 12:46 AM, Benjamin Marzinski wrote:
> 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.
> 
Which would be cool.
I was actually hoping to meet you in Raleigh last week, but then it
didn't work out.

>>> 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.
>  
Couldn't agree more.
Let's drop them.

>>> 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.
> 
Hmm. Actually, I quite like the systemd integration; it allows me to
signal the internal multipathd state back to systemd:

# systemctl status multipathd
multipathd.service - Device-Mapper Multipath Device Controller
   Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled)
   Active: active (running) since Wed 2016-04-27 12:39:59 CEST; 19h ago
 Main PID: 6913 (multipathd)
   Status: "idle"
   CGroup: /system.slice/multipathd.service
           └─6913 /sbin/multipathd -d -s

Which I find quite neat. And I guess we should be able to overcome
the manually started issue by checking if the socket is present, and
just execute a 'reconfigure' command if so.
Let me see ...

> 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.
> 
>  
Hmm. Actually, I do like the 'nompath' checking; we do lack the
capability of switching off multipath from the kernel commandline
ATM. So yes, we should be including that bit.

As for /etc/multipath.conf ... The original setup has been shipping
without any multipath.conf file. So I would be okay with this change
if we can guarantee that /etc/multipath.conf will always be existing.
Seeing that you're running 'multipath -A' to add any wwids, wouldn't
that be sufficient?
IE why do we need the check for /etc/multipath.conf here; couldn't
we make 'multipath -A' return non-zero to avoid multipathd to be
started?

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)