Bug 1689051

Previous in rhel7 we can prevent running sm-notify by touch a file "/var/lib/nfs/statd/sm.ha" because:
~~~~~~~~~~~~~
[root ~]# rpm -q nfs-utils
nfs-utils-1.3.0-0.61.el7.x86_64
[root ~]# systemctl cat rpc-statd-notify | grep sm.ha
ConditionPathExists=!/var/lib/nfs/statd/sm.ha
~~~~~~~~~~~~~

However, now in rhel8 we have just removed that "ConditionPathExists" to keep pace with the upstream version:
~~~~~~~~~~~~~
[root ~]# rpm -q nfs-utils
nfs-utils-2.3.3-15.el8.x86_64
[root ~]# systemctl cat rpc-statd-notify | grep sm.ha
[root ~]# systemctl cat rpc-statd-notify
# /usr/lib/systemd/system/rpc-statd-notify.service
[Unit]
Description=Notify NFS peers of a restart
DefaultDependencies=no
Wants=network-online.target
After=local-fs.target network-online.target nss-lookup.target

# if we run an nfs server, it needs to be running before we
# tell clients that it has restarted.
After=nfs-server.service

PartOf=nfs-utils.service

[Service]
Type=forking
ExecStart=-/usr/sbin/sm-notify
RemainAfterExit=yes
[root ~]# 
~~~~~~~~~~~~~

I'm not sure whether this function is still needed or not for HA in RHEL8.
Here just file a bug to track it and please feel free to close it if it's not necessary.


+++ This bug was initially created as a clone of Bug #1182692 +++

Description of problem:

This breaks the HA-NFS use case.

Previously, in 7.0, sm-notify ran as a result of statd. We could disable statd from launching sm-notify by putting STATDARGS=--no-notify in /etc/sysconfig/nfs.

Now, in 7.1 sm-notify has its own systemd service file, rpc-statd-notify.service. The nfs-server service now requires that the notify service launches as it's own service after nfs-server launches.

you can see that here. 

# cat /usr/lib/systemd/system/nfs-server.service  | grep notify
Wants=rpc-statd-notify.service
Before= rpc-statd-notify.service

The HA NFS use-case must have complete control over when the sm-notify command executes. We can not have systemd controlling that service for us in any automated fashion as a result of nfs-server starting. Like i mentioned earlier, we achieved this control in 7.0 by using 'STATDARGS=--no-notify'. Now that sm-notify executes outside of statd, we have no control.

The reasoning for all of this is we have to delay sm-notify from executing until our exports and floating IP have initiated. These resources are controlled by the cluster, not systemd, so there is no way for systemd to delay sm-notify correctly. There has been a lot of work done to make the NFSv3 lock recovery work correctly in the HA NFS use case. All of that work hinges on the cluster having complete control over sm-notify, not systemd.

Version-Release number of selected component (if applicable):

How reproducible:
100%

Steps to Reproduce:
1. set STATDARGS=--no-notify in /etc/sysconfig/nfs
2. execute systemctl start nfs-server

Actual results:

In var/log/messages during systemctl start nfs-server

Jan 14 11:37:30 localhost systemd: Starting Notify NFS peers of a restart...
Jan 14 11:37:30 localhost sm-notify: sm-notify: Version 1.3.0 starting
Jan 14 11:37:30 localhost sm-notify: sm-notify: No hosts to notify; exiting
Jan 14 11:37:30 localhost systemd: Started Notify NFS peers of a restart.


Expected results:

we don't want to see sm-notify executing during systemctl start nfs-server

Additional info:

--- Additional comment from David Vossel on 2015-01-30 01:36:29 CST ---

(In reply to Eryu Guan from comment #9)
> Hi David,
> 
> Does current fix work for you? Stop sm-notify from starting along with
> nfs-server by "mkdir /var/lib/nfs/statd/sm.ha"?
> 
> If so, QE will verify this bug and track the --no-notify doesn't work issue
> in another bug.
> 
> Thanks,
> Eryu

Eryu,

I'll explain the fix.

The HA NFS Active/Passive use case uses a cluster resource-agent to start/stop/monitor the NFS server. As part of the that use case the resource-agent always creates the /var/lib/nfs/statd/sm.ha directory before starting starting the NFS server. That directory has to do with how the NFSv3 lock recovery data is failed over between nodes. We're guaranteed the directory exists when the HA NFS resource-agent is being used.

The HA NFS use case wants complete control over sm-notify. Steve's fix accurately detects when the HA NFS use case is being deployed, and suppresses automatically firing off the sm-notify command outside of the cluster's control.

This is not a permanent solution. The correct solution is to figure out how to to get 'STATDARG=--no-notify' to work properly again like it did in 7.0... For now this fix makes HA NFS work though.

I have tested this package and it suppressed systemd launching sm-notify in my environment.

-- David