Por que o Fedora iniciaria o rpc-statd-notify.service, mas não o rpc-statd.service?

Question

Notei que rpc-statd-notify.service foi iniciado no meu laptop Fedora 28 Workstation.

Isso parece ser apenas porque nfs-client.target está ativado no meu laptop. É bastante plausível que eu tenha ativado isso em algum momento no passado. Então, isso responde a questão principal que eu tinha ...

Mas, em seguida, percebo que, por contraste, rpc.statd não foi iniciado no meu sistema. Isso não causaria um problema?

$ 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
rpc-statd-notify.service
● ├─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.

Eu fiquei me perguntando, se existe uma razão pela qual o Fedora tem como padrão dar suporte à reinicialização de um sistema cliente NFSv3, mas não suporta a reinicialização do sistema do servidor? Ou seja reinicializar o servidor quebrará os bloqueios mantidos pelo cliente. Parece que isso pode ser uma falha irritante.

    

Answer 1

Aparentemente, mount.nfs organizará a exibição de rpc-statd.service sob demanda, se necessário. Presumivelmente, isso evita iniciar rpc.statd em clientes NFSv4, portanto, significa que não há uso desnecessário de recursos, etc.

$ systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target

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

# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service

[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.target

    

Answer 2

Parece que perder rpc-statd causaria uma falha visível nos clientes NFS. Então, isso seria notado pelo administrador e corrigido antes de causar qualquer problema sutil com bloqueio.

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.

link

Por outro lado, a falta de rpc-statd-notify pode ser facilmente ignorada, e isso pode fazer com que efeitos indesejáveis (bloqueios obsoletos) persistam no servidor. Então, talvez seja bom ter algo que incentiva a ativação ...

Não parece haver muita documentação oficial do Redhat para iniciar o NFSv3 (e o Google não é super útil também). Documentos mais antigos tradicionalmente envolvem a ativação de vários serviços, e o daemon rpc.statd costuma ser mencionado como parte disso.

Mas suspeito que essa inconsistência signifique que ainda é muito provável que as pessoas habilitem o rpc-statd e ignorem a necessidade de ativar o rpc-statd-notify. Especialmente porque parece que em tempos anteriores o serviço que iniciou o rpc-statd poderia ter feito o próprio bit de notificação - eu vejo o rpc-statd.service configurando RPC_STATD_NO_NOTIFY=1 .

Assim, se nfs-client.target não for iniciado automaticamente e não houver documentação para mencioná-lo como um dos serviços a serem ativados, o acima parecerá uma justificativa fraca. E pode ser melhor explicado como sendo apenas velho, negligenciado e confuso.

Isso também não parece ser uma resposta muito sólida. Deve ter havido uma razão específica em algum ponto para não deixar o rpc.statd fazer a parte de notificação por si próprio.

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.