I noticed rpc-statd-notify.service was started on my Fedora 28 Workstation laptop.

This appears to be only because nfs-client.target is enabled on my laptop. It is quite plausible I enabled that at some point in the past. So that answers the main question I had...

But then I notice that by contrast, rpc.statd is not started on my system. Wouldn't this cause a problem?

$ systemctl status rpc-statd-notify
● rpc-statd-notify.service - Notify NFS peers of a restart
   Loaded: loaded (/usr/lib/systemd/system/rpc-statd-notify.service; static; vendor preset: disabled)
   Active: active (exited) since Tue 2018-05-08 08:02:24 BST; 4h 55min ago
  Process: 1451 ExecStart=/usr/sbin/sm-notify $SMNOTIFYARGS (code=exited, status=0/SUCCESS)

May 08 08:02:23 alan-laptop systemd[1]: Starting Notify NFS peers of a restart...
May 08 08:02:24 alan-laptop sm-notify[1451]: Version 3.1.1 starting
May 08 08:02:24 alan-laptop systemd[1]: Started Notify NFS peers of a restart.

$ systemctl list-dependencies --reverse rpc-statd-notify
● ├─nfs-server.service
● ├─nfs-utils.service
● └─nfs-client.target
●   ├─multi-user.target
●   └─remote-fs.target

$ systemctl status nfs-client.target
● nfs-client.target - NFS client services
   Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; vendor preset: disabled)
   Active: active since Tue 2018-05-08 08:01:52 BST; 5h 28min ago

May 08 08:01:52 alan-laptop systemd[1]: Reached target NFS client services.

man sm-notify

File locks are not part of persistent file system state. Lock state is thus lost when a host reboots.

Network file systems must also detect when lock state is lost because a remote host has rebooted. After an NFS client reboots, an NFS server must release all file locks held by applications that were running on that client. After a server reboots, a client must remind the server of file locks held by applications running on that client.

For NFS version 2 and version 3, the Network Status Monitor protocol (or NSM for short) is used to notify NFS peers of reboots. On Linux, two separate user-space components constitute the NSM service:

  • sm-notify

    A helper program that notifies NFS peers after the local system reboots

  • rpc.statd

    A daemon that listens for reboot notifications from other hosts, and manages the list of hosts to be notified when the local system reboots

The local NFS lock manager alerts its local rpc.statd of each remote peer that should be monitored. When the local system reboots, the sm- notify command notifies the NSM service on monitored peers of the reboot. When a remote reboots, that peer notifies the local rpc.statd, which in turn passes the reboot notification back to the local NFS lock manager.

I am left wondering, if there is a reason why Fedora would default to supporting rebooting an NFSv3 client system, but not support rebooting the server system? I.e. rebooting the server will break the locks held by the client. It sounds like it could be an annoying oversight.

2 Answers 2


Apparently mount.nfs will arrange to start rpc-statd.service on demand if needed. Presumably this avoids starting rpc.statd on NFSv4 clients, so it means there is no unnecessary resource usage etc.

$ systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
Description=NFS client services

# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.

# GSS services dependencies and ordering
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service


It looks like missing rpc-statd would cause a nice visible failure on NFS clients. So this would be noticed by the admin and corrected before it caused any subtle problem with locking.

Jul 08 17:24:20 mount[957]: mount.nfs: rpc.statd is not running but is required for remote locking. Jul 08 17:24:20 mount[957]: mount.nfs: Either use '-o nolock' to keep locks local, or start statd.


By contrast, missing rpc-statd-notify could easily be overlooked, and this might cause undesirable effects (stale locks) to persist on the server. So maybe it's nice to have something that encourages it to be enabled...

There doesn't seem to be much official Redhat documentation for starting NFSv3 anymore (and Google isn't super helpful either). Older docs traditionally involve enabling a bunch of services anyway, and the rpc.statd daemon tends to be mentioned as part of that.

But I suspect this inconsistency means it's still rather likely for people to enable rpc-statd and overlook the need to enable rpc-statd-notify. Especially since it looks like in earlier times the service which started rpc-statd might have done the notify bit itself - I see rpc-statd.service is setting RPC_STATD_NO_NOTIFY=1.

So if nfs-client.target is not started automatically, and there's no documentation to mention it as one of the services to enable, the above seems like a weak justification. And it might be better explained as just being old, neglected, and messy.

That doesn't seem a very solid answer either though. There must have been a specific reason at some point for not just letting rpc.statd doing the notify part on it's own.

Note: the sm-notify command contains a check to ensure it runs only once after each system reboot. This prevents spurious reboot notification if rpc.statd restarts without the [--no-notify] option.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .