Red Hat Bugzilla – Bug 980580
rpc.statd service using /sbin
Last modified: 2013-07-23 15:04:31 EDT
Description of problem:
is using the path /sbin/rpc.statd
while all other nfs services are using
This should be fixed.
There is symlink:
nfslock.service -> nfs-lock.service
any reason for this symlink?
Maybe related, I get a failed nfs-lock service:
Seems like something is starting rpc.statd before is should:
root$ service nfs-lock status
Redirecting to /bin/systemctl status nfs-lock.service
nfs-lock.service - NFS file locking service.
Loaded: loaded (/usr/lib/systemd/system/nfs-lock.service; enabled)
Active: failed (Result: exit-code) since ti. 2013-07-02 20:47:35 CEST; 16s ago
Process: 1609 ExecStart=/sbin/rpc.statd $STATDARG (code=exited, status=1/FAILURE)
Process: 1605 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig (code=exited, status=0/SUCCESS)
juli 02 20:47:35 example.com rpc.statd: Statd service already running!
juli 02 20:47:35 example.com systemd: nfs-lock.service: control process exited, code=exited status=1
juli 02 20:47:35 example.com systemd: Failed to start NFS file locking service..
juli 02 20:47:35 example.com systemd: Unit nfs-lock.service entered failed state.
However rpc.statd is running:
root$ ps -ef|grep rpc.statd
rpcuser 898 1 0 20:46 ? 00:00:00 rpc.statd --no-notify
root 1941 995 0 20:48 pts/1 00:00:00 grep --color=auto rpc.statd
or is this a systemd bug?
In regards to nfs-lock.service failing to start, I opened Bug 983915, which may be related to the same thing you are seeing. "rpc.statd --no-notify" is usually what is called by NFS mount if /var/run/rpc.statd.pid does have a valid statd running pid in it.
Do you have any NFS mounts in /etc/fstab that get mounted at boot? If so, I think that is what is starting your rpc.statd and causing nfs-lock.service to fail since rpc.statd is already running.
(In reply to Terje RÃ¸sten from comment #0)
> Description of problem:
> is using the path /sbin/rpc.statd
> while all other nfs services are using
> This should be fixed.
Its on /sbin so NFS root will work. The same reason
mount.nfs is on /sbin as well...
> There is symlink:
> nfslock.service -> nfs-lock.service
> any reason for this symlink?
So the "service nfslock" interface will work.