Bug 690828

Summary: Providing multipath native systemd file for upcoming F15 Feature Systemd
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: agk, bmarzins, dwysocha, fdinitto, heinzm, lpoetter, lvm-team, mbroz, msnitzer, prajnoha, prockai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-17 17:22:58 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 713562    
Description Flags
Native systemd service file for multipathd
The relevant stop section from the old SysV init script
minor fixes to multipathd.service
Iscsid startup order added none

Description Jóhann B. Guðmundsson 2011-03-25 10:31:39 EDT
Created attachment 487575 [details]
Native systemd service file for multipathd

Description of problem:

This is a futile attempt to create native systemd service files for multipathd ;)  

You probably want to add fedora-multipathd-init which checks and setup multipathd if no /etc/multipathd.conf exists which then would be called with ExecStartPre=/lib/systemd/fedora-multipathd-init or have that setup in a seprate service file that gets run once?

Anywho the attached file is a native systemd file for upcoming F15 Feature [1]

Please read [2] on how to packaging and installing systemd Service files.

To learn more about Systemd daemon see [3].

To view old SysV with the new Systemd site by site see for your component see

If you have any question dont hesitate to ask them on this bug report.





Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jóhann B. Guðmundsson 2011-03-25 10:33:00 EDT
Created attachment 487576 [details]
The relevant stop section from the old SysV init script
Comment 2 Bill Nottingham 2011-04-26 13:35:27 EDT
Moving systemd service RFEs to rawhide.

At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades.

We therefore request:
- wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes.
- work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release.
- do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy
Comment 3 Jóhann B. Guðmundsson 2011-06-27 09:40:28 EDT
What's the current status on this?

We need this in rawhide as soon as possible unless ofcourse you guys want to block alpha.. 

Comment 4 Jóhann B. Guðmundsson 2011-06-28 15:03:40 EDT
Just out of curiosity is this service applicant for hardware activation
unfortunately our guidelines are a bit short on how to do that 

"Hardware activation

Hardware activation occurs when a service is installed but only turns on if a
certain type of hardware is installed. Enabling of the service is normally done
with a udev rule. At this time we do not have further guidance on how to write
those udev rules. The service itself installs its .service files in the normal
places and are installed by the normal systemd scriptlets. These services
should never be enabled by the package as they will be enabled by udev. "

But you can read man systemd.device and look at the bluetooth service which is
doing that I believe..
Comment 5 Jóhann B. Guðmundsson 2011-07-11 09:57:23 EDT
Given how alpha is closing fast I'm going to start the non-responsive policy for this component.

Note no comments since the initial day this bug got filed. 

Mentioned this on upstream mailing list no response there either. 

Comment 6 Alasdair Kergon 2011-07-11 10:09:01 EDT
Ben/Peter - please take a look at this one.
Comment 7 Milan Broz 2011-07-11 14:48:11 EDT
The unit file is quite trivial. But the shudtdown script is curious.

The whole point of that script is to say "hey, I have root on multipath device, do not stop multipathd yet.".

multipathd is just killed afterwards, so isn't better move that service to the end and remove that script completely? Dunno.

Anyway, using this script in ExecStop makes no sense - it will kill multipatd, just it will return failure for unit.
Comment 8 Jóhann B. Guðmundsson 2011-07-11 15:12:03 EDT
Basically the problem we need to solve is this section from the legacy sysv init script

"       root_dev=$(awk '{ if ($1 !~ /^[ \t]*#/ && $2 == "/") { print $1; }}' /etc/mtab)
        dm_num=`dmsetup info -c --noheadings -o minor $root_dev 2> /dev/null`
        if [ $? -eq 0 ]; then
                [ -d $syspath/$root_dm_device ] && teardown_slaves $syspath/$root_dm_device

That can be put into a seperate bash script that will be executed on when systemctl stop multipathd is run ( note if that script returns failure systemctl wont bring down the service ) 

If that part is not necessary then just remove it
Comment 9 Jóhann B. Guðmundsson 2011-07-11 15:22:40 EDT
Created attachment 512279 [details]
minor fixes to multipathd.service

Adding the missing on reload "killproc $DAEMON -HUP" behaviour comment out ExecStop= 

I should mention that we can split this into more then one ExecStop command since they get parsed sequentially

As in 

ExecStop= perform check if on root ( if returned failure it will not stop the daemon ) 
ExecStop= stop if check returns success 
( if there is some stop command that needs to be done if not systemd will kill the service by itself and you dont need this extra line  )
Comment 10 Ben Marzinski 2011-07-11 15:32:32 EDT
Multipathd keeps the path devices open, so that it can test their health.  This was causing problems with iscsi shutting down correctly, so multipathd's shutdown was moved before iscsi's. However, taking down the iscsi daemon temporarily fails all IO with DID_BUS_BUSY. This causes an all-paths-down situation on multipath, and if multipathd is dead, and you're set to queue, and this happens to your root device, shutdown hangs (BZ 456228).

But it does seem possible that multipath should be able to shutdown after the iscsi daemon does.
Comment 11 Jóhann B. Guðmundsson 2011-07-11 15:56:57 EDT
Created attachment 512285 [details]
Iscsid startup order added

This will start multipathd before iscsi iscsid services are started and shutdown after they have stopped.
Comment 12 Jóhann B. Guðmundsson 2011-07-11 15:59:14 EDT
(In reply to comment #11)
> Created attachment 512285 [details]
> Iscsid startup order added
> This will start multipathd before iscsi iscsid services are started and
> shutdown after they have stopped.

Shutdown after they have been shutdown in the shutdown order and started before they get started in the bootup order
Comment 13 Ben Marzinski 2011-07-12 10:02:14 EDT
Looks reasonable. I'll run some tests, and then rebuild the device-mapper-multipath package.

Milan, I didn't see any packages that had a subpackage for the SysV init scripts.  Is there some standard naming convention we're supposed to use for these?  What are you using for the lvm2 packages?
Comment 14 Milan Broz 2011-07-12 10:28:26 EDT
(In reply to comment #13)
> Milan, I didn't see any packages that had a subpackage for the SysV init
> scripts.  Is there some standard naming convention we're supposed to use for
> these?  What are you using for the lvm2 packages?

As discussed, see mdadm package, it is already built and is very similar to multipath needs. Packaging policy is here http://fedoraproject.org/wiki/Packaging/SysVInitScript
Comment 15 Jóhann B. Guðmundsson 2011-07-15 10:56:22 EDT
If you dont have the time to package this but are happy with those unit files  should I try to find a proven packager to do this for you? 

Comment 16 Ben Marzinski 2011-07-19 18:47:13 EDT
There's a new build with the systemd unit file included (device-mapper-multipath-0.4.9-17.fc16)


However, to make the system boot correctly with multipath, you also need the patch available at