Bug 980580 - rpc.statd service using /sbin
Summary: rpc.statd service using /sbin
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-02 18:47 UTC by Terje Røsten
Modified: 2013-07-23 19:04 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-23 19:04:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Terje Røsten 2013-07-02 18:47:28 UTC
Description of problem:

/usr/lib/systemd/system/nfs-lock.service

is using the path /sbin/rpc.statd

while all other nfs services are using

 /usr/sbin/rpc.*

This should be fixed.

There is symlink: 

nfslock.service -> nfs-lock.service

any reason for this symlink?

Comment 1 Terje Røsten 2013-07-02 18:53:14 UTC
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[1609]: Statd service already running!
juli 02 20:47:35 example.com systemd[1]: nfs-lock.service: control process exited, code=exited status=1
juli 02 20:47:35 example.com systemd[1]: Failed to start NFS file locking service..
juli 02 20:47:35 example.com systemd[1]: 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?

nfs-utils-1.2.8-2.0.fc19.x86_64
3.9.8-300.fc19.x86_64
systemd-204-9.fc19.x86_64

Comment 2 Jason 2013-07-12 09:36:16 UTC
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.

Comment 3 Steve Dickson 2013-07-23 19:04:31 UTC
(In reply to Terje Røsten from comment #0)
> Description of problem:
> 
> /usr/lib/systemd/system/nfs-lock.service
> 
> is using the path /sbin/rpc.statd
> 
> while all other nfs services are using
> 
>  /usr/sbin/rpc.*
> 
> 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.


Note You need to log in before you can comment on or make changes to this bug.