FS#41126 - [nfs-utils] [shutdown] rpc-statd-notify.service should not run after network-online.target?

Attached to Project: Arch Linux
Opened by Patrick Donnelly (batrick) - Monday, 07 July 2014, 19:56 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 24 February 2015, 07:46 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Using nfs-utils 1.3.0-3, rpc-statd-notify.service hangs if the systemd-networkd-wait-online.service does not finish. Using:

After=network.target nss-lookup.target

instead of

After=network-online.target nss-lookup.target

corrects the problem.
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 24 February 2015, 07:46 GMT
Reason for closing:  Fixed
Additional comments about closing:  upstream fix added to 1.3.2-4
Comment by aaaaaaaaaaaaaaaaaaaa (Pyroh) - Monday, 25 August 2014, 01:05 GMT
This fixes the issue I've been having for the past ~2 months, where NFS shares weren't being unmounted prior to shutdown.

The pertinent portions of my fstab:
192.168.1.11:/mnt/pnas/media /mnt/media nfs rw,noatime,noauto,nofail,x-systemd.automount,x-systemd.device-timeout=10,timeo=14 0 0
192.168.1.11:/mnt/pnas/music /mnt/music nfs ro,noatime,noauto,nofail,x-systemd.automount,x-systemd.device-timeout=10,timeo=14 0 0
192.168.1.11:/mnt/pnas/backups /mnt/backups nfs rw,noatime,noauto,nofail,x-systemd.automount,x-systemd.device-timeout=10,timeo=14 0 0
192.168.1.11:/mnt/pnas/watch /mnt/watch nfs rw,noatime,noauto,nofail,x-systemd.automount,x-systemd.device-timeout=10,timeo=14 0 0

Prior to this, the following would happen very consistently: systemd would hang at "Reached Shutdown Target" (if I hadn't run 'sudo umount /mnt/*' beforehand),
and wait ~1:30 before presumably killing the offending process and proceeding to actually poweroff/reboot. I just tried this modification out and it worked multiple times in a row,
with nfsiostat being used to verify before each shutdown that at least one share was indeed mounted.

Anyways, is the patch in question viable for application? Or is network-online.target preferable for some reason? If the former is the case, then I'd be happy to report this upstream. It doesn't look like any fixes have been commited for the service file in question:

http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=history;f=systemd/rpc-statd-notify.service;h=6b13b323e7585059cd526649c8dccdd70a623119;hb=HEAD
Comment by aaaaaaaaaaaaaaaaaaaa (Pyroh) - Monday, 25 August 2014, 23:14 GMT
After reading up on the various documentation available for systemd service files, I'm not convinced my previously mentioned remedy is optimal. Apparently network-online.target being considered reached (e.g. the network is up) is handled by the network management utility. If that's the case, then something isn't right with connman.service. Could someone who's actually knowledgeable about systemd's unit files chime in?

Edit: It's worth mentioning that changing network-online.target to network.target does somewhat fix the issue. NFS mounts are unmounted before shutdown, so there's no stop job, but if I boot with my rfkill switch on then I get 4 nfs mount failures in journald. nofail is a flag for all nfs mounts so it's not a huge issue, but not everyone uses those flags.
Comment by Patrick Donnelly (batrick) - Thursday, 25 September 2014, 17:47 GMT
Why is this still open?
Comment by Tobias Powalowski (tpowa) - Thursday, 05 February 2015, 14:08 GMT
This is still open because I don't think network.target is the correct solution for this.

Loading...