Bug 769879 - nfs-server.service needs to be split up
nfs-server.service needs to be split up
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-22 10:49 EST by Kay Sievers
Modified: 2013-07-12 12:34 EDT (History)
9 users (show)

See Also:
Fixed In Version: nfs-utils-1.2.8-1.1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-27 22:17:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
New set of units for nfs-utils (1.07 KB, application/x-bzip)
2012-01-11 11:04 EST, Jóhann B. Guðmundsson
no flags Details

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.