multipath-0.5.0 still provides broken udev rules

multipath-0.5.0 still provides broken udev rules

[Peter Volkov]

[-- Attachment #1.1: Type: text/plain, Size: 636 bytes --]

Hi, guys.

There is a problem: udev does not create partitions for multipath devices
in case I use kpartx.rules provided with multipath sources. I found that
udev always go to kpartx_end after following line of rules:
ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"

There is 8 (!!!) years old thread that discusses this problem:
https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html

So what is the current state? Should we fix udev rules for multipath or
should we create better patch for dmsetup.c? Meanwhile I've copied
multipath.rules from redhat and partitions are created as they should.


With best regards,
--
Peter.

[-- Attachment #1.2: Type: text/html, Size: 1622 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: multipath-0.5.0 still provides broken udev rules

[Zdenek Kabelac]

On 25.4.2016 12:52, Peter Volkov wrote:
> Hi, guys.
>
> There is a problem: udev does not create partitions for multipath devices in
> case I use kpartx.rules provided with multipath sources. I found that udev
> always go to kpartx_end after following line of rules:
> ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"

Hi

Just curious - what would you want to do with inactive table???
You cannot read/scan such device ?



>
> There is 8 (!!!) years old thread that discusses this problem:
> https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html
>
> So what is the current state? Should we fix udev rules for multipath or should
> we create better patch for dmsetup.c? Meanwhile I've copied multipath.rules
> from redhat and partitions are created as they should.


What is the exact problem you do have/see ?

Can you describe in some single repeatable steps a reproducer ?

Which distro are you talking about  (Fedora ? Debian ??)

Have you opened any bugzilla anywhere ?


Regard

Zdenek

Re: multipath-0.5.0 still provides broken udev rules

[Peter Volkov]

[-- Attachment #1.1: Type: text/plain, Size: 2123 bytes --]

On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote:

> On 25.4.2016 12:52, Peter Volkov wrote:
>>
>> There is a problem: udev does not create partitions for multipath devices
>> in
>> case I use kpartx.rules provided with multipath sources. I found that udev
>> always go to kpartx_end after following line of rules:
>> ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
>>
>
> Just curious - what would you want to do with inactive table???
>

Actually don't understand what's this table and what's wrong with that.
There is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is
such variable in udev rules file that comes with multipath sources:
http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD


> You cannot read/scan such device ?


The problem I have - multipath with udev's help creates /dev/mapper/mpatha
block device but does not create devices for partitions, e.g.
/dev/mapper/mpatha1. I found that this happens due to udev rule mentioned
above. After execution rule on line 10 (*ENV{DM_TABLE_STATE}!="LIVE",
GOTO="kpartx_end"*) udev goes directly to kpartx_end and rule on line 45
(..."/sbin/kpartx -u -p -part /dev/$name") is never executed.


> There is 8 (!!!) years old thread that discusses this problem:
>> https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html
>>
>> So what is the current state? Should we fix udev rules for multipath or
>> should
>> we create better patch for dmsetup.c? Meanwhile I've copied
>> multipath.rules
>> from redhat and partitions are created as they should.
>>
>
>
> What is the exact problem you do have/see ?

Can you describe in some single repeatable steps a reproducer ?
>

Install udev rules file from mutlipath tools and see that partitions are
not created.


> Which distro are you talking about  (Fedora ? Debian ??)
>

That's Gentoo. But I think any distro that uses whatever upstream prepares
have this problem.


> Have you opened any bugzilla anywhere ?
>

Not yet. I'd like to understand what needs to be done first.

--
Peter.

[-- Attachment #1.2: Type: text/html, Size: 4429 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: multipath-0.5.0 still provides broken udev rules

[Zdenek Kabelac]

On 25.4.2016 14:10, Peter Volkov wrote:
> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com
> <mailto:zkabelac@redhat.com>> wrote:
>
>     On 25.4.2016 12:52, Peter Volkov wrote:
>
>         There is a problem: udev does not create partitions for multipath
>         devices in
>         case I use kpartx.rules provided with multipath sources. I found that udev
>         always go to kpartx_end after following line of rules:
>         ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
>
>
>     Just curious - what would you want to do with inactive table???
>
>
> Actually don't understand what's this table and what's wrong with that. There
> is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such
> variable in udev rules file that comes with multipath sources:
> http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD


So you would need to figure out which rules would have set  DM_TABLE_STATE 
before ?  (I assume such have never existed...)

In Fedora/RHEL  these  kpartx.rules are not packaged as they are likely some 
'ancient' rules - IMHO  most of that file is useless on today's distros.
(Unsure about dm-wwn logic???)

So it's rather question for upstream kpartx maintainer why these rules
are not maintained in any way.

Vars like DM_TABLE_STATE are simply not created by dm rules.

kpartx rules comes from year 2007, while dm rules started to be maintained in 
2009 - that may explain few things as well...

> That's Gentoo. But I think any distro that uses whatever upstream prepares
> have this problem.
>
>     Have you opened any bugzilla anywhere ?
>
>
> Not yet. I'd like to understand what needs to be done first.
>

Likely Gentoo should not install obsoleted udev rules file.

Regards

Zdenek

PS: I could be wrong here - since I've nothing in common with multipath,
so in such case - feel free to correct me....

Re: multipath-0.5.0 still provides broken udev rules

[Peter Volkov]

[-- Attachment #1.1: Type: text/plain, Size: 1967 bytes --]

On Mon, Apr 25, 2016 at 3:32 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote:

> On 25.4.2016 14:10, Peter Volkov wrote:
>
>> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com
>> <mailto:zkabelac@redhat.com>> wrote:
>>
>>     On 25.4.2016 12:52, Peter Volkov wrote:
>>
>>         There is a problem: udev does not create partitions for multipath
>>         devices in
>>         case I use kpartx.rules provided with multipath sources. I found
>> that udev
>>         always go to kpartx_end after following line of rules:
>>         ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
>>
>> Actually don't understand what's this table and what's wrong with that.
>> There
>> is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such
>> variable in udev rules file that comes with multipath sources:
>>
>> http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD
>>
>
>
> So you would need to figure out which rules would have set  DM_TABLE_STATE
> before ?  (I assume such have never existed...)
>

There was a patch suggested for dmsetup:
https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html

So it's rather question for upstream kpartx maintainer why these rules
> are not maintained in any way.
>

Yup,  that's why I'm here.

kpartx rules comes from year 2007, while dm rules started to be maintained
> in 2009 - that may explain few things as well...


Then your suggestion is to fix udev rules that comes with multipath. Ok.

That's Gentoo. But I think any distro that uses whatever upstream prepares
>> have this problem.
>>
>

> Likely Gentoo should not install obsoleted udev rules file.
>

That's true. Yet I'm not talking about Gentoo here, but about config file
that comes with multipath sources and according to multipath homepage this
mailing list is a right place for such discussions. Please, correct me if
I'm wrong.

--
Peter.

[-- Attachment #1.2: Type: text/html, Size: 4436 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: multipath-0.5.0 still provides broken udev rules

[Christophe Varoqui]

[-- Attachment #1.1: Type: text/plain, Size: 2574 bytes --]

Hi,

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 ?

Best regards,


On Mon, Apr 25, 2016 at 2:32 PM, Zdenek Kabelac <zkabelac@redhat.com> wrote:

> On 25.4.2016 14:10, Peter Volkov wrote:
>
>> On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac <zkabelac@redhat.com
>> <mailto:zkabelac@redhat.com>> wrote:
>>
>>     On 25.4.2016 12:52, Peter Volkov wrote:
>>
>>         There is a problem: udev does not create partitions for multipath
>>         devices in
>>         case I use kpartx.rules provided with multipath sources. I found
>> that udev
>>         always go to kpartx_end after following line of rules:
>>         ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
>>
>>
>>     Just curious - what would you want to do with inactive table???
>>
>>
>> Actually don't understand what's this table and what's wrong with that.
>> There
>> is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is such
>> variable in udev rules file that comes with multipath sources:
>>
>> http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD
>>
>
>
> So you would need to figure out which rules would have set  DM_TABLE_STATE
> before ?  (I assume such have never existed...)
>
> In Fedora/RHEL  these  kpartx.rules are not packaged as they are likely
> some 'ancient' rules - IMHO  most of that file is useless on today's
> distros.
> (Unsure about dm-wwn logic???)
>
> So it's rather question for upstream kpartx maintainer why these rules
> are not maintained in any way.
>
> Vars like DM_TABLE_STATE are simply not created by dm rules.
>
> kpartx rules comes from year 2007, while dm rules started to be maintained
> in 2009 - that may explain few things as well...
>
> That's Gentoo. But I think any distro that uses whatever upstream prepares
>> have this problem.
>>
>>     Have you opened any bugzilla anywhere ?
>>
>>
>> Not yet. I'd like to understand what needs to be done first.
>>
>>
> Likely Gentoo should not install obsoleted udev rules file.
>
> Regards
>
> Zdenek
>
> PS: I could be wrong here - since I've nothing in common with multipath,
> so in such case - feel free to correct me....
>
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>

[-- Attachment #1.2: Type: text/html, Size: 4003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: multipath-0.5.0 still provides broken udev rules

[Peter Volkov]

[-- Attachment #1.1: Type: text/plain, Size: 813 bytes --]

On Mon, Apr 25, 2016 at 3:56 PM, Christophe Varoqui <
christophe.varoqui@opensvc.com> wrote:

> Distributors can't be asked to agree on a common udev ruleset.
>

Of course, there is no pressure on downstream distributor on what
configuration/udev rules should be used. Yet it's always good to have
upstream hand for such things. Lot's of packages
(lvm/systemd/networkmanager/...) come with an upstream suggested udev
rules. Should we avoid use of that udev rules? I don't think so.

Ben, Hannes, Xosé, Peter are you ok with my deleting the udev rules example
> ?
>

Since these rules are broken it good idea to drop this file to avoid
confusion. Yet it's good idea to document some general ideas of what needs
to be done with udev to setup fully working multipath configuration.

--
Peter.

[-- Attachment #1.2: Type: text/html, Size: 1478 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: multipath-0.5.0 still provides broken udev rules

[Hannes Reinecke]

On 04/25/2016 12:52 PM, Peter Volkov wrote:
> Hi, guys.
> 
> There is a problem: udev does not create partitions for multipath
> devices in case I use kpartx.rules provided with multipath sources.
> I found that udev always go to kpartx_end after following line of rules:
> ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
> 
> There is 8 (!!!) years old thread that discusses this problem:
> https://www.redhat.com/archives/dm-devel/2007-July/msg00095.html
> 
> So what is the current state? Should we fix udev rules for multipath
> or should we create better patch for dmsetup.c? Meanwhile I've
> copied multipath.rules from redhat and partitions are created as
> they should.
> 
> 
Sigh. I really need to post my multipath update.
Stay tuned.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@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)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: multipath-0.5.0 still provides broken udev rules

[Benjamin Marzinski]

On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote:
>    Hi,
>    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 ?

I am personally fine with kpartx.rules being deleted. Red Hat doesn't
package it.

-Ben

>    Best regards,
>    On Mon, Apr 25, 2016 at 2:32 PM, Zdenek Kabelac <[1]zkabelac@redhat.com>
>    wrote:
> 
>      On 25.4.2016 14:10, Peter Volkov wrote:
> 
>        On Mon, Apr 25, 2016 at 1:58 PM, Zdenek Kabelac
>        <[2]zkabelac@redhat.com
>        <mailto:[3]zkabelac@redhat.com>> wrote:
> 
>            On 25.4.2016 12:52, Peter Volkov wrote:
> 
>                There is a problem: udev does not create partitions for
>        multipath
>                devices in
>                case I use kpartx.rules provided with multipath sources. I
>        found that udev
>                always go to kpartx_end after following line of rules:
>                ENV{DM_TABLE_STATE}!="LIVE", GOTO="kpartx_end"
> 
>            Just curious - what would you want to do with inactive table???
> 
>        Actually don't understand what's this table and what's wrong with
>        that. There
>        is no traces of DM_TABLE_STATE variable in lvm2 sources. Yet there is
>        such
>        variable in udev rules file that comes with multipath sources:
>        [4]http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD
> 
>      So you would need to figure out which rules would have set 
>      DM_TABLE_STATE before ?  (I assume such have never existed...)
> 
>      In Fedora/RHEL  these  kpartx.rules are not packaged as they are likely
>      some 'ancient' rules - IMHO  most of that file is useless on today's
>      distros.
>      (Unsure about dm-wwn logic???)
> 
>      So it's rather question for upstream kpartx maintainer why these rules
>      are not maintained in any way.
> 
>      Vars like DM_TABLE_STATE are simply not created by dm rules.
> 
>      kpartx rules comes from year 2007, while dm rules started to be
>      maintained in 2009 - that may explain few things as well...
> 
>        That's Gentoo. But I think any distro that uses whatever upstream
>        prepares
>        have this problem.
> 
>            Have you opened any bugzilla anywhere ?
> 
>        Not yet. I'd like to understand what needs to be done first.
> 
>      Likely Gentoo should not install obsoleted udev rules file.
> 
>      Regards
> 
>      Zdenek
>      PS: I could be wrong here - since I've nothing in common with multipath,
>      so in such case - feel free to correct me....
> 
>      --
>      dm-devel mailing list
>      [5]dm-devel@redhat.com
>      [6]https://www.redhat.com/mailman/listinfo/dm-devel
> 
> References
> 
>    Visible links
>    1. mailto:zkabelac@redhat.com
>    2. mailto:zkabelac@redhat.com
>    3. mailto:zkabelac@redhat.com
>    4. http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=kpartx/kpartx.rules;h=022361f907e873ac16fc75459b88af34b27576e5;hb=HEAD
>    5. mailto:dm-devel@redhat.com
>    6. https://www.redhat.com/mailman/listinfo/dm-devel

> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Re: multipath-0.5.0 still provides broken udev rules

[Xose Vazquez Perez]

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 ?

getuid/usb_id
kpartx/kpartx_id
kpartx/kpartx.rules
multipath/01_udev
multipath/02_multipath
multipath/11-dm-mpath.rules
multipath.conf.annotated
multipath.conf.defaults
multipath.conf.synthetic
multipathd/multipathd.init.debian
multipathd/multipathd.init.redhat
multipathd/multipathd.init.suse
multipathd/multipathd.service
multipathd/multipathd.socket
multipath/multipath.init.suse
multipath/multipath.rules
multipath-tools.spec.in

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: multipath-0.5.0 still provides broken udev rules

[Hannes Reinecke]

On 04/25/2016 07:38 PM, Benjamin Marzinski wrote:
> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote:
>>    Hi,
>>    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 ?
> 
> I am personally fine with kpartx.rules being deleted. Red Hat doesn't
> package it.
> 
Well, we do. We use kpartx to generate partitions for multipath and
dmraid, so we do need this rule.
Please do not delete it; if so I will only have to re-add it again
in a SUSE-specific patch.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@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)

Re: multipath-0.5.0 still provides broken udev rules

[Hannes Reinecke]

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 ?
> 
> 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)

> 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?

> 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.

> 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@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)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: multipath-0.5.0 still provides broken udev rules

[Zdenek Kabelac]

On 26.4.2016 07:43, Hannes Reinecke wrote:
> On 04/25/2016 07:38 PM, Benjamin Marzinski wrote:
>> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote:
>>>     Hi,
>>>     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 ?
>>
>> I am personally fine with kpartx.rules being deleted. Red Hat doesn't
>> package it.
>>
> Well, we do. We use kpartx to generate partitions for multipath and
> dmraid, so we do need this rule.
> Please do not delete it; if so I will only have to re-add it again
> in a SUSE-specific patch.

Hi

Can you please elaborate what is the 'specific' need of SUSE for patch?

AFAIK there should be no need for it - all identifiers are not tracked by
10-dm.rules

It has whole logic about device state built-in.

So what exactly would you need to trace in kpartx.rules ?

Regards

Zdenek

Re: multipath-0.5.0 still provides broken udev rules

[Hannes Reinecke]

On 04/26/2016 10:39 AM, Zdenek Kabelac wrote:
> On 26.4.2016 07:43, Hannes Reinecke wrote:
>> On 04/25/2016 07:38 PM, Benjamin Marzinski wrote:
>>> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote:
>>>>     Hi,
>>>>     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 ?
>>>
>>> I am personally fine with kpartx.rules being deleted. Red Hat
>>> doesn't
>>> package it.
>>>
>> Well, we do. We use kpartx to generate partitions for multipath and
>> dmraid, so we do need this rule.
>> Please do not delete it; if so I will only have to re-add it again
>> in a SUSE-specific patch.
> 
> Hi
> 
> Can you please elaborate what is the 'specific' need of SUSE for patch?
> 
> AFAIK there should be no need for it - all identifiers are not
> tracked by
> 10-dm.rules
> 
> It has whole logic about device state built-in.
> 
> So what exactly would you need to trace in kpartx.rules ?
> 
We use kpartx.rules to call 'kpartx' itself for creating the
partition devices on top of any multipath or dmraid devices.

If that logic has been moved into other, generic, device-mapper
rules please let me know.
But until then we need the kpartx.rules. file.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@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)

Re: multipath-0.5.0 still provides broken udev rules

[Zdenek Kabelac]

On 26.4.2016 10:47, Hannes Reinecke wrote:
> On 04/26/2016 10:39 AM, Zdenek Kabelac wrote:
>> On 26.4.2016 07:43, Hannes Reinecke wrote:
>>> On 04/25/2016 07:38 PM, Benjamin Marzinski wrote:
>>>> On Mon, Apr 25, 2016 at 02:56:35PM +0200, Christophe Varoqui wrote:
>>>>>      Hi,
>>>>>      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 ?
>>>>
>>>> I am personally fine with kpartx.rules being deleted. Red Hat
>>>> doesn't
>>>> package it.
>>>>
>>> Well, we do. We use kpartx to generate partitions for multipath and
>>> dmraid, so we do need this rule.
>>> Please do not delete it; if so I will only have to re-add it again
>>> in a SUSE-specific patch.
>>
>> Hi
>>
>> Can you please elaborate what is the 'specific' need of SUSE for patch?
>>
>> AFAIK there should be no need for it - all identifiers are not
>> tracked by
>> 10-dm.rules
>>
>> It has whole logic about device state built-in.
>>
>> So what exactly would you need to trace in kpartx.rules ?
>>
> We use kpartx.rules to call 'kpartx' itself for creating the
> partition devices on top of any multipath or dmraid devices.
>
> If that logic has been moved into other, generic, device-mapper
> rules please let me know.
> But until then we need the kpartx.rules. file.

Ok, so it seems it is completely chaotic -

As in RHEL/Fedora there is largely hacked  mpath udev rule file,
which is then responsible for using partx?

While in SUSE this seems to be handled by broken old unmaintained  kpartx udev 
rules file (as the file is useless - wondering how could do anything useful on 
SUSE)

AFAIK seems we miss communication between Ben with Hannes here :)

As logically it seem  calling  kpartx rule calls belong to  kpartx package.
However  kpartx upstream rule file is for  systems  from 2007 year.

So I'd have assumed lots of current mpath  RHEL rule patches should be
relocated to kpartx rules.

Leaving this to you guys...

Regards

Zdenek

Re: 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@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)

Re: 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@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)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: multipath-0.5.0 still provides broken udev rules

[Benjamin Marzinski]

On Thu, Apr 28, 2016 at 08:23:44AM +0200, Hannes Reinecke wrote:
> On 04/28/2016 12:46 AM, Benjamin Marzinski wrote:
> > 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.
> 
Here is a heavily commented copy of our rules file.
----------

SUBSYSTEM!="block", GOTO="end_mpath"
ACTION!="add|change", GOTO="end_mpath"
# If /etc/multipath.conf doesn't exist or multipathing is disabled
# on the kernel commandline, we do nothing.
IMPORT{cmdline}="nompath"
ENV{nompath}=="?*", GOTO="end_mpath"
TEST!="/etc/multipath.conf", GOTO="end_mpath"

ENV{DEVTYPE}=="partition", IMPORT{parent}="DM_MULTIPATH_DEVICE_PATH"
ENV{DM_MULTIPATH_DEVICE_PATH}=="1", ENV{ID_FS_TYPE}="mpath_member", \
	GOTO="end_mpath"

ENV{MPATH_SBIN_PATH}="/sbin"
TEST!="$env{MPATH_SBIN_PATH}/multipath", ENV{MPATH_SBIN_PATH}="/usr/sbin"

# I know that we run the multipath rules later that SUSE does (after blkid
# runs, for one thing), but I've never seen the issue that caused Hannes to
# add the -u option. I don't see any reason why we couldn't use it however.
#
# Also, we only unconditionally check if the device is a multipath device
# on addition, because it takes a while, and we've run into issues where
# udev times out if we do it on every change event.
ACTION=="add", ENV{DM_MULTIPATH_DEVICE_PATH}!="1", \
	PROGRAM=="$env{MPATH_SBIN_PATH}/multipath -c $tempnode", \
	ENV{DM_MULTIPATH_DEVICE_PATH}="1", ENV{ID_FS_TYPE}="mpath_member"

ACTION!="change", GOTO="update_timestamp"
# Load some variables from the database. The new ones will get explained
# down below
IMPORT{db}="DM_MULTIPATH_TIMESTAMP"
IMPORT{db}="DM_MULTIPATH_DEVICE_PATH"
IMPORT{db}="DM_MULTIPATH_WIPE_PARTS"
IMPORT{db}="DM_MULTIPATH_NEED_KPARTX"

# o.k. this whole next part is so hacky, it will make your eyes bleed.
# The idea is sound, however. Like I mentioned above, I was seeing udev
# timeout issues when I checked the path on every change event. My idea
# to stop this was to have multipathd write out a timestamp when it
# starts, and update this whenever a new path is added to the wwids file
# or the configuration is reload. If neither of these thing has happened,
# then rechecking the path will give you the same answer as before, so
# it's not necessary. The the udev rules could read in the timestamp file,
# check it against the existing timestamp, and only run this check if
# the timestamp was different. The problem is that there is no way to do
# that in the udev rules. You can compare variables to constants. You
# can assign variables to other variables, but you can't compare
# variables to other variables. I've filed a bug and sent emails about this
# to the udev people, but I haven't gotten any response. So, as a
# workaround, I added a multipath option, -T, which does the timestamp
# comparison as soon as multipath starts up, and if they're equal, simply
# returns the value you passed in with the timestamp. It's not as fast as
# not execing multipath at all, but it is enough faster to fix the issue
# I was seeing. But this should really be fixed in the udev rules, not
# in multipath.  That's why I've never posted this upstream. It's a hack.
#
# But the general idea here is that this is where multipath checks devices
# on change events instead of add events.
PROGRAM=="$env{MPATH_SBIN_PATH}/multipath -T $env{DM_MULTIPATH_TIMESTAMP}:$env{DM_MULTIPATH_DEVICE_PATH} -c $env{DEVNAME}", \
	ENV{DM_MULTIPATH_DEVICE_PATH}="1", ENV{ID_FS_TYPE}="mpath_member", \
	GOTO="update_timestamp"

# If the device isn't part of a multipath device, clear these
ENV{DM_MULTIPATH_DEVICE_PATH}=""
ENV{DM_MULTIPATH_WIPE_PARTS}=""

LABEL="update_timestamp"
# This deletes the partition devnodes from any multipath path device. We want
# to be careful to only run this once. If the users recreates the partition
# devices for some reason, we don't want to keep blowing them away. That's why
# we set DM_MULTIPATH_WIPE_PARTS and import it on future events.
ENV{DM_MULTIPATH_DEVICE_PATH}=="1", ENV{DM_MULTIPATH_WIPE_PARTS}!="1", \
	ENV{DM_MULTIPATH_WIPE_PARTS}="1", \
	RUN+="/sbin/partx -d --nr 1-1024 $env{DEVNAME}"

# this sets DM_MULTIPATH_TIMESTAMP
IMPORT{file}="/run/multipathd/timestamp"

LABEL="check_kpartx"
# This is where we create the kpartx partitions
KERNEL!="dm-*", GOTO="end_mpath"
# This sets the link priority for all multipath and kpartx devices
# so that udev creates the /dev/disk/by-* symlinks to them instead of
# to the path devices.
ENV{DM_UUID}=="mpath-?*|part[0-9]*-mpath-?*", OPTIONS+="link_priority=10"
ACTION!="change", GOTO="end_mpath"
ENV{DM_UUID}!="mpath-?*", GOTO="end_mpath"
# We don't want to run kpartx on every change event (which will happen
# whenever multipathd reloads the table). So only run it in the same
# situations where lvm would scan the device. However, sometimes
# multipath is suspended when this happens. In that case, we use
# DM_MULTIPATH_NEED_KPARTX to remember that we need to run kpartx
# when the next event is generated (and since the device is suspended
# the next even should be arriving shortly)
ENV{DM_ACTIVATION}=="1", ENV{DM_MULTIPATH_NEED_KPARTX}="1"
ENV{DM_SUSPENDED}=="1", GOTO="end_mpath"
ENV{DM_ACTION}=="PATH_FAILED", GOTO="end_mpath"
ENV{DM_ACTIVATION}!="1", ENV{DM_MULTIPATH_NEED_KPARTX}!="1", GOTO="end_mpath"
RUN+="$env{MPATH_SBIN_PATH}/kpartx -a $tempnode", \
	ENV{DM_MULTIPATH_NEED_KPARTX}=""
LABEL="end_mpath"

Re: multipath-0.5.0 still provides broken udev rules

[Benjamin Marzinski]

On Thu, Apr 28, 2016 at 08:23:44AM +0200, Hannes Reinecke wrote:
> On 04/28/2016 12:46 AM, Benjamin Marzinski wrote:
> > 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?

The idea with checking for /etc/multipath.conf is exactly that it
doesn't ship with one.  This way, even if multipath is installed on the
system, it isn't automatically enabled.  Obviously, simply touching
/etc/multipath.conf is enough for a default config. This isn't super
necessary in the multipathd.service file, because you need to enable
the service for it to run, but I do this to match the checks in the
multipath.rules file.

All that's involved in this is the check in multipathd.service, the
check in multipath.rules, and a small bit of code that gets run when
multipath starts, and exits with a warning if you don't have a
configuration file. I belive I posted this years ago, and it got Nak'ed.
I'm fine if upstream doesn't want to do things this way.

multipath -A won't create a configuration file, it will just add any
WWIDs from the kernel commandline to the wwids file. I see them as two
entirely seperate things. Like I said above, the multipath.rules checks
for /etc/multipath.conf as well. You really need the conditions for when
multipath is enabled to match between these two files.

-Ben

> 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		   Teamlead Storage & Networking
> hare@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)

Distributions mpt code

[Xose Vazquez Perez]

On 04/29/2016 12:10 AM, Benjamin Marzinski wrote:

> On Thu, Apr 28, 2016 at 08:23:44AM +0200, Hannes Reinecke wrote:
>> On 04/28/2016 12:46 AM, Benjamin Marzinski wrote:
>>> 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.
>>
> Here is a heavily commented copy of our rules file.

FYI, distributions repositories of MPT are at:
openSUSE/SLES: https://github.com/hreinecke/multipath-tools
Fedora/RH: http://pkgs.fedoraproject.org/cgit/rpms/device-mapper-multipath.git/
Debian: https://anonscm.debian.org/git/pkg-lvm/multipath-tools.git

multipath-tools: irrelevant files

[Xose Vazquez Perez]

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:
>>> 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.

Hi Christophe, more files could be deleted as Benjamin and
Hannes have suggested in this thread.

I sent also four patches last month, and they're still pending:
https://www.redhat.com/archives/dm-devel/2016-April/thread.html#00453


BTW, there are not new tar files at http://christophe.varoqui.free.fr/ ,
latest is 0.5.0

-thanks-

Re: multipath-tools: irrelevant files

[Christophe Varoqui]

[-- Attachment #1.1: Type: text/plain, Size: 4702 bytes --]

Hi Xose,

this 4-patch patchset to janitor the project header files is now merged,
and more files deleted (specfile template and suse example sysv init
script).

Do you care if I don't publish tarballs anymore ? I'd rather deprecate this
http://christophe.varoqui.free.fr/  website usage. The gitweb at
git.opensvc.com offers the tarball extraction from version tags, for people
who don't want to clone the git project.

Best regards,
Christophe Varoqui
OpenSVC

On Thu, May 19, 2016 at 5:24 PM, Xose Vazquez Perez <xose.vazquez@gmail.com>
wrote:

> 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:
> >>> 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.
>
> Hi Christophe, more files could be deleted as Benjamin and
> Hannes have suggested in this thread.
>
> I sent also four patches last month, and they're still pending:
> https://www.redhat.com/archives/dm-devel/2016-April/thread.html#00453
>
>
> BTW, there are not new tar files at http://christophe.varoqui.free.fr/ ,
> latest is 0.5.0
>
> -thanks-
>

[-- Attachment #1.2: Type: text/html, Size: 6524 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

multipath-tools: web

[Xose Vazquez Perez]

On 06/01/2016 05:05 PM, Christophe Varoqui wrote:

> Do you care if I don't publish tarballs anymore ? I'd rather deprecate this
> http://christophe.varoqui.free.fr/  website usage. The gitweb at git.opensvc.com
> <http://git.opensvc.com> offers the tarball extraction from version tags,
> for people who don't want to clone the git project.

You should add a note to redirect people to gitweb.
And replace this message:
"Latest release : multipath-tools-0.5.0.tar.bz2"