Red Hat Bugzilla – Full Text Bug Listing
|Summary:||nfs-server.service needs to be split up|
|Product:||[Fedora] Fedora||Reporter:||Kay Sievers <kay>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||bfields, ipilcher, jlayton, johannbg, johannbg, mathieu-acct, mattdm, metherid, steved|
|Fixed In Version:||nfs-utils-1.2.8-1.1.fc19||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-05-27 22:17:49 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kay Sievers 2011-12-22 10:49:51 EST
Systemd does not allow long running processes to be started in Pre and Post sections. It's a bug that this is possible, and we are about to fix it. All individial services need to be started by individual service files to be supervised by systemd. Alternatively, it can all be stared with by some wrapper script, but that way, it will not be able to use any advanced feature of systemd. As mentioned in email a while back, newer versions of systemd will force-kill all remaining processes that are still running when the Pre and Post section are left during a unit start transaction. The current service file is expected to fail in Fedora 17. Please fix it, to integrate properly with systemd's requirements. Thanks!
Comment 1 Kay Sievers 2012-01-10 21:59:48 EST
Systemd is now fixed, to clean the cgroup properly between the unit startup transactions. This will land in rawhide now. The current version of the nfs service file can not work with rawhide and F17. Please split it up to individual units, or wrap it in a shell script if proper systemd is not the goal or impossible. Please let us know if there are any remaining questions. Thanks!
Comment 2 Jóhann B. Guðmundsson 2012-01-11 11:04:51 EST
Created attachment 552154 [details] New set of units for nfs-utils Here is a new set of unit files that should be acceptable by upstream and usable across distributions using systemd and not be affected by this change in systemd Note that nfs is now using it's own target and any reference to /etc/sysconfig has been dropped since it's obsolete and to make it cross distributable. If users want to add variables to unit or otherwise edit them they should copy them to /etc/systemd/system directory and edit them there. To test this replace the unit files with the once you already have installed on F15+ and run # systemctl daemon-reload # systemctl enable nfs.target nfs-server.service # mkdir -p /tmp/test # echo "/tmp/test 192.168.1.0/255.255.255.0(ro,sync,no_subtree_check)" > /etc/exports.d/test.exports # systemctl start nfs-server.service # systemctl status nfs-server.service nfs-rquotad.service nfs-mountd.service nfs-idmap.service # showmount -e # netstat -pant | grep rpc # systemctl stop nfs-server.service # systemctl status nfs-server.service nfs-rquotad.service nfs-mountd.service nfs-idmap.service Reboot to check if the unit are not correctly started after reboot. Note the the rpc.mountd is exiting with a non clean exit code when stop which might indicate a bug in the daemon.
Comment 3 Mathieu Chouquet-Stringer 2012-03-14 16:50:15 EDT
Hello, Not only you need to split the service because of systemd but also because rpc.idmapd is also needed by the NFS client (not just the server)... Should that be a different bug?
Comment 4 Fedora Update System 2012-05-15 16:21:18 EDT
nfs-utils-1.2.6-0.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/nfs-utils-1.2.6-0.fc17
Comment 5 Fedora Update System 2012-05-17 18:56:54 EDT
Package nfs-utils-1.2.6-0.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.6-0.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-7979/nfs-utils-1.2.6-0.fc17 then log in and leave karma (feedback).
Comment 6 Fedora Update System 2012-05-29 12:18:41 EDT
nfs-utils-1.2.6-0.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Comment 7 Jóhann B. Guðmundsson 2012-06-07 14:16:01 EDT
We just had a filing a mis-filing a report against systemd where the reporter is mentioning he cant disable nfs anywho when testing it, it looks like you did not pull in the whole set of submitted units so at least nfs-lock.service is installed into the multi-user.target instead of the nfs.target + showmount -e seems to be error-ing out "clnt_create: RPC: Unknown host" ( probably another bug ) To duplicate just do 1."yum -y install nfs-utils" 2. follow steps in Comment 2 3. reboot 4. run systemctl disable nfs.target 6. reboot notice that nfs-lock.service is enable and active ( would have otherwise been disabled when the target got disabled )
Comment 8 Jóhann B. Guðmundsson 2013-05-06 11:49:26 EDT
See that you reopened this bug.. If you are going to be fixing the units then fix it and nfs so that nfs4 on root works ( Im pretty sure RHEL 7 will need to support that ;) )...
Comment 9 Rahul Sundaram 2013-05-06 15:01:05 EDT
just to be clear, I reopened this bug since it appears unfixed. I will leave it upto the maintainer to fix it however.
Comment 10 Fedora Update System 2013-05-07 14:02:18 EDT
nfs-utils-1.2.8-1.1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-6676/nfs-utils-1.2.8-1.1.fc19
Comment 11 Fedora Update System 2013-05-07 16:45:48 EDT
Package nfs-utils-1.2.8-1.1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.8-1.1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6676/nfs-utils-1.2.8-1.1.fc19 then log in and leave karma (feedback).
Comment 12 Fedora Update System 2013-05-27 22:17:49 EDT
nfs-utils-1.2.8-1.1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Comment 13 Ian Pilcher 2013-07-08 21:05:25 EDT
(In reply to Jóhann B. Guðmundsson from comment #2) > # systemctl enable nfs.target nfs-server.service Can someone explain why this is a good thing and/or necessary?
Comment 14 Jóhann B. Guðmundsson 2013-07-09 02:24:22 EDT
(In reply to Ian Pilcher from comment #13) > (In reply to Jóhann B. Guðmundsson from comment #2) > > # systemctl enable nfs.target nfs-server.service > > Can someone explain why this is a good thing and/or necessary? It's pretty self explanatory but which one of those the target, the service or both? Why dont you try to explain why you do not think this is necessary?
Comment 15 Ian Pilcher 2013-07-09 15:29:56 EDT
I'm trying to understand what benefit nfs.target provides. In Fedora 18, turning on the NFS server required "systemctl enable nfs-server.service"; now one also has to enable the target. Since the only thing in nfs.target.wants is a symlink to nfs-server.service, I don't see what's being gained.
Comment 16 Jóhann B. Guðmundsson 2013-07-10 14:31:21 EDT
(In reply to Ian Pilcher from comment #15) > I'm trying to understand what benefit nfs.target provides. > > In Fedora 18, turning on the NFS server required "systemctl enable > nfs-server.service"; now one also has to enable the target. Since the only > thing in nfs.target.wants is a symlink to nfs-server.service, I don't see > what's being gained. Manageability look at the share number of units and their share dependency. General rule of thumb is 5+ unit for an component or application belong in a target. It's simple enough for example RHEl to enable the nfs target by default and the command would be same.
Comment 17 Ian Pilcher 2013-07-10 15:32:37 EDT
(In reply to Jóhann B. Guðmundsson from comment #16) > Manageability look at the share number of units and their share dependency. Hmm ... nfs-server.service still has 6 dependencies, but it looks like 3 of them could be removed, since they're now pulled in by nfs.target. > General rule of thumb is 5+ unit for an component or application belong in a > target. Well I'm not sure that it makes sense to convert a service to target *solely* because it has a lot of dependencies, but I can certainly see the benefit of grouping *common* dependencies (a set of dependencies that are shared by multiple services) into something. That something could then be required by those services. I'm unconvinced, though, that those services should be *WantedBy* that target. It seems more intuitive to me for them to *Require* it. In this scheme, nfs-server.service might look like this: [Unit] Description=NFS Server Requires=nfs-idmapd.service nfs-mountd.service nfs-rquotad.service Requires=nfs.target After=network.target named.service nfs-lock.service After=nfs.target [Service] ... [Install] WantedBy=multi-user.target The seems more idiomatic to me, perhaps because nfs-server is a top-level "meta-service". Perhaps it should itself be a target? Regardless, this is getting off-topic for Bugzilla. Thank you for answering my questions.