FS#42033 - [nfs-utils] [boot] 1.3.0 & systemd: start job "Notify NFS peers" runs 15 minutes
Attached to Project:
Arch Linux
Opened by Stefan Förster (HotblackDesiato) - Saturday, 20 September 2014, 09:05 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 05 February 2015, 14:03 GMT
Opened by Stefan Förster (HotblackDesiato) - Saturday, 20 September 2014, 09:05 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 05 February 2015, 14:03 GMT
|
Details
Description:
I have a server in my home LAN with an NFS server. Four of my computers (all Arch Linux, regularly updated) access an NFS share of this server during boot. This has worked for years and still works on three machines. On one of my two desktops nfs-utils version 1.3.0-3 results in a systemd message during boot: "A start job is running for Notify NFS peers of a restart (... min ... sec / no limit)". It takes about 15 minutes (!) for the boot process to continue. I have just downgraded nfs-utils to 1.2.9-5 which mitigated this problem. Steps to reproduce: not sure - I can only repro it on one of four Linux boxes in my network. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Thursday, 05 February 2015, 14:03 GMT
Reason for closing: Fixed
Additional comments about closing: 1.3.2
Thursday, 05 February 2015, 14:03 GMT
Reason for closing: Fixed
Additional comments about closing: 1.3.2
When the boot process gets stuck, the computer is already connected to the (wired) network: I can ping it and even ssh into it (though it replies "System is booting up. See pam_nologin(8)" and doesn't provide a shell)
The NFS server is running FreeBSD, not sure if it is relevant.
There are some NFS shares configured in `/etc/fstab` on the client, but they have the option "noauto". Here is the content of `/etc/systemd/system` on the client:
<pre>
$ find /etc/systemd/system/
/etc/systemd/system/
/etc/systemd/system/getty.target.wants
/etc/systemd/system/getty.target.wants/getty@tty1.service
/etc/systemd/system/basic.target.wants
/etc/systemd/system/basic.target.wants/hddapm.service
/etc/systemd/system/multi-user.target.wants
/etc/systemd/system/multi-user.target.wants/rpcbind.service
/etc/systemd/system/multi-user.target.wants/ntpd.service
/etc/systemd/system/multi-user.target.wants/cronie.service
/etc/systemd/system/multi-user.target.wants/lighttpd.service
/etc/systemd/system/multi-user.target.wants/nsd.service
/etc/systemd/system/multi-user.target.wants/sshd.service
/etc/systemd/system/multi-user.target.wants/rpc-mountd.service
/etc/systemd/system/multi-user.target.wants/rpc-gssd.service
/etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.service
/etc/systemd/system/multi-user.target.wants/nfs-client.target
/etc/systemd/system/multi-user.target.wants/remote-fs.target
/etc/systemd/system/display-manager.service
/etc/systemd/system/remote-fs.target.wants
/etc/systemd/system/remote-fs.target.wants/nfs-client.target
/etc/systemd/system/sysinit.target.wants
</pre>
Downgrading nfs-utils to version 1.2.9-5 indeed fixes the issue.
For clients only nfs-client.target is needed.
Cleanup your rpc* services they are all activated as they are needed.
rpcbind, rpc-mountd rpc-gssd etc. remove them from /etc/systemd/*
This is fixed in 1.3.2.