Bug 769879

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!

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.

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?

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

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).

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.

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 )

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 ;) )...

just to be clear, I reopened this bug since it appears unfixed.  I will leave it upto the maintainer to fix it however.

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

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).

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.

(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?

(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?

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.

(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.

(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.