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@xxxxxxx +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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel