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 [4] If you have any question dont hesitate to ask them on this bug report. 1.http://fedoraproject.org/wiki/Features/systemd 2.https://fedoraproject.org/wiki/Systemd_Packaging_Draft 3.http://0pointer.de/public/systemd-man/daemon.html 4.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 487576 [details] The relevant stop section from the old SysV init script
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
What's the current status on this? We need this in rawhide as soon as possible unless ofcourse you guys want to block alpha.. https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd http://fedoraproject.org/wiki/Packaging:Tmpfiles.d
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..
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. https://www.redhat.com/archives/dm-devel/2011-June/msg00104.html
Ben/Peter - please take a look at this one.
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.
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 root_dm_device="dm-$dm_num" [ -d $syspath/$root_dm_device ] && teardown_slaves $syspath/$root_dm_device fi " 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
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 )
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.
Created attachment 512285 [details] Iscsid startup order added This will start multipathd before iscsi iscsid services are started and shutdown after they have stopped.
(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
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?
(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
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? https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
There's a new build with the systemd unit file included (device-mapper-multipath-0.4.9-17.fc16) http://koji.fedoraproject.org/koji/buildinfo?buildID=253934 However, to make the system boot correctly with multipath, you also need the patch available at https://bugzilla.redhat.com/show_bug.cgi?id=723357