FS#39863 - [nfs-utils] rpc.statd: failed to create RPC listeners, exiting.

Attached to Project: Arch Linux
Opened by René Herman (rene) - Tuesday, 15 April 2014, 05:37 GMT
Last edited by Tobias Powalowski (tpowa) - Saturday, 05 July 2014, 19:59 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 0
Private No

Details

Description:

This *could* be mostly a documentation "bug" (or a systemd issue) but the internet is, and my logs were for the longest time, riddled with the error message from the subject line, from various distributions. That is...

I use NFS mostly for connecting to gadgets such as NAS units and digital media players all of which are old enough to use NFSv3 exclusively. I therefore need NFS client "only" and need rpc.statd running, but have with the documentation currently available on the Wiki been for the longest time apparently unable to do this right -- as many users are, judging by the amount of google hits said error message produces.

Specifically, "systemctl enable rpc-statd" is apparently not right, since this is on current arch not enough to keep the error from being produced for NFSv3 mounts from /etc/fstab at boot. If I'm not mistaken, it used to be right back when NFSv3 was current but I'm not sure anymore.

This is seemingly due to a dependency issue/bug with respect to "remote-fs-pre.target"; only after manually digging though the systemd dependency tree did I figure out that a (the?) way to get things functioning right was to "systemctl enable nfs-client.target". Although that works well, I quite doubt that THAT in fact is "right" since I, firstly, don't believe that ".target" files are supposed to be specifically enabled like that and secondly since enabling "nfs-server.target" does not actually work for the server side of things...

As such, and although I eventually got things working correctly, I believe I might still be looking at some sort of dependency bug in the nfs-utils service file(s)?

If not: is enabling nfs-utils.target in fact the right way and would it be possible for someone with a better understanding of NFS and overview over its versions to make things more explicit on the NFS wiki page? As said, the internet is riddled with this error message -- but given that things do still work, people end up ignoring the error and I haven't been able to find an answer anywhere.

Additional info:

* package version(s)

nfs-utils 1.2.9-5 (current) and previous versions.

* config and/or log files etc.

apr 12 22:54:31 e600 rpc.statd[241]: Version 1.2.9 starting
apr 12 22:54:31 e600 rpc.statd[241]: Flags: TI-RPC
apr 12 22:54:31 e600 rpc.statd[242]: Version 1.2.9 starting
apr 12 22:54:31 e600 rpc.statd[242]: Flags: TI-RPC
apr 12 22:54:31 e600 rpc.statd[243]: Version 1.2.9 starting
apr 12 22:54:31 e600 rpc.statd[243]: Flags: TI-RPC
apr 12 22:54:31 e600 rpc.statd[243]: Running as root. chown /var/lib/nfs to choose different user
apr 12 22:54:31 e600 rpc.statd[242]: Running as root. chown /var/lib/nfs to choose different user
apr 12 22:54:31 e600 rpc.statd[241]: Running as root. chown /var/lib/nfs to choose different user
apr 12 22:54:31 e600 rpc.statd[243]: failed to create RPC listeners, exiting
apr 12 22:54:31 e600 rpc.statd[241]: failed to create RPC listeners, exiting
apr 12 22:54:31 e600 rpc.statd[242]: failed to create RPC listeners, exiting

[ ... ]

apr 12 22:54:43 e600 mount[228]: mount.nfs: rpc.statd is not running but is required for remote locking.
apr 12 22:54:43 e600 mount[228]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
apr 12 22:54:43 e600 mount[228]: mount.nfs: an incorrect mount option was specified
apr 12 22:54:43 e600 systemd[1]: mnt-readynas-backup.mount mount process exited, code=exited status=32
apr 12 22:54:43 e600 systemd[1]: Failed to mount /mnt/readynas/backup.
apr 12 22:54:43 e600 systemd[1]: Unit mnt-readynas-backup.mount entered failed state.
apr 12 22:54:43 e600 mount[229]: mount.nfs: rpc.statd is not running but is required for remote locking.
apr 12 22:54:43 e600 mount[229]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
apr 12 22:54:43 e600 mount[229]: mount.nfs: an incorrect mount option was specified
apr 12 22:54:43 e600 systemd[1]: mnt-netcenter.mount mount process exited, code=exited status=32
apr 12 22:54:43 e600 systemd[1]: Failed to mount /mnt/netcenter.
apr 12 22:54:43 e600 systemd[1]: Unit mnt-netcenter.mount entered failed state.
apr 12 22:54:43 e600 mount[227]: mount.nfs: rpc.statd is not running but is required for remote locking.
apr 12 22:54:43 e600 mount[227]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
apr 12 22:54:43 e600 mount[227]: mount.nfs: an incorrect mount option was specified
apr 12 22:54:43 e600 systemd[1]: mnt-readynas-media.mount mount process exited, code=exited status=32
apr 12 22:54:43 e600 systemd[1]: Failed to mount /mnt/readynas/media.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Saturday, 05 July 2014, 19:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  1.3.0-2
Comment by René Herman (rene) - Tuesday, 15 April 2014, 05:45 GMT
Forgot to mention: only setting NEED_STATD="yes" in /etc/conf.d/nfs-common.conf did not work to get things working (although, I guess, that's obvious since even manually enabling rpc-statd didn't).
Comment by René Herman (rene) - Tuesday, 22 April 2014, 18:48 GMT
Okay, after some further probing; the issue seems to be that rpc-statd.service isn't part of nfs-client.target. That is...

Firstly, the issue is that NFS mounts from /etc/fstab are being run before rpc.statd has been launched, even after explicitly enabling "rpc-statd.service". Things can be worked around by, as per the above, enabling nfs-client.target since it positions itself AFTER rpc-statd and BEFORE remote-fs-pre-target, thereby forcing correct ordering... which doesn't actuyally seem to be an all-bad work-around.

More to the point though -- it's in the end caused by rpc-statd.service proclaiming itsef to be part only of "nfs-server.target" and not of "nfs-client.target". If it were, no manual enabling of nfs-client.target would be needed and making it so indeed works fine as well:

cp /lib/systemd/system/rpc-statd.service /etc/systemd/system/

and addd nfs-client.target to its "Before=" and "PartOf=" lines.

I take it that rpc-statd.service is not at the moment a standard part of nfs-client.target since it is not needed for NFS v4... but this would seem to imply that only NFSv4-ONLY systems boot correctly at the moment? I noticed the "NEED_STATD" variable in /etc/conf.d/nfs-common.conf but what is in fact supposed to use this variable? There's certainly nothing in /lib/systemd on my system that references it.

So, summarising: fixing the multiple rpc.statd startups for NFSv3 mounts from /etc/fstab by manually enabling nfsclient.target doesn't in fact seem all that "wrong" -- but not needing to do so would clearly be better. How one might arrange to not need to do this depends on how and what is supposed to use that NEED_STATD variable. Can anyone comment on that?
Comment by Tobias Powalowski (tpowa) - Wednesday, 18 June 2014, 13:29 GMT
Please try latest nfs-utils-1.3.0 from [testing] it uses now the upstream provided systemd files.
Comment by James A. Langbridge (jlangbridge) - Saturday, 05 July 2014, 10:12 GMT
I've had the same problem as the OP. I've been trying to connect to a NetGear ReadyNAS NV+ that only supports NFSv3. The new package from testing works for me. Thank you!
EDIT: Confirmed on a second laptop

Loading...