| Message ID | 20160427224601.GG26117@octiron.msp.redhat.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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
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" -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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) -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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- -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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- > -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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" -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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