rpc-statd-notify.serviceFedora 28 워크스테이션 노트북에서 시작되는 것을 발견했습니다 .
nfs-client.target내 노트북에 활성화되어 있기 때문인 것 같습니다 . 아마도 과거 어느 시점에 이 기능을 활성화했을 것입니다. 이것은 내 주요 질문에 대한 답변입니다 ...
그러나 대조적으로 rpc.statd내 시스템에서는 시작되지 않았다는 것을 알았습니다. 이로 인해 문제가 발생하지 않습니까?
$ 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
파일 잠금은 영구 파일 시스템 상태의 일부가 아닙니다. 따라서 호스트를 재부팅하면 잠금 상태가 손실됩니다.
네트워크 파일 시스템은 원격 호스트 재부팅으로 인해 잠금 상태가 손실되는 시기도 감지해야 합니다. NFS 클라이언트가 다시 시작된 후 NFS 서버는 클라이언트에서 실행 중인 애플리케이션이 보유한 모든 파일 잠금을 해제해야 합니다. 서버가 다시 시작된 후 클라이언트는 클라이언트에서 실행 중인 응용 프로그램이 보유한 파일 잠금을 서버에 알려야 합니다.
NFS 버전 2 및 3의 경우 네트워크 상태 모니터 프로토콜(또는 줄여서 NSM)을 사용하여 NFS 피어에 다시 시작하도록 알립니다. Linux에서는 두 개의 독립적인 사용자 공간 구성 요소가 NSM 서비스를 구성합니다.
SMS 알림
로컬 시스템이 다시 시작된 후 NFS 피어에게 알리는 도우미
rpc.statd
다른 호스트의 재시작 알림을 수신하고 로컬 시스템이 재시작될 때 알림을 받을 호스트 목록을 관리하는 데몬
로컬 NFS 잠금 관리자는 모니터링해야 하는 각 원격 피어에 대해 로컬 rpc.statd에 경고합니다. 로컬 시스템이 다시 시작되면 sm-notify 명령은 모니터링되는 피어의 NSM 서비스에 다시 시작하도록 알립니다. 원격 재부팅이 발생하면 피어는 로컬 rpc.statd에 알리고 다시 로컬 NFS 잠금 관리자에 재부팅 알림을 전달합니다.
Fedora가 기본적으로 NFSv3 클라이언트 시스템 재시작을 지원하지만 서버 시스템 재시작을 지원하지 않는지 알고 싶습니다. 이유가 있습니까? 즉, 서버를 다시 시작하면 클라이언트가 보유한 잠금이 해제됩니다. 이는 성가신 감독일 수도 있을 것 같습니다.
답변1
필요한 경우 주문형 출시가 분명히 준비될 것입니다 mount.nfs. rpc-statd.service아마도 이는 rpc.statdNFSv4 클라이언트에서 시작하는 것을 방지하므로 불필요한 리소스 사용 등이 없음을 의미합니다.
$ 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
답변2
rpc-statd손실로 인해 NFS 클라이언트에 명백한 오류가 발생하는 것으로 보입니다 . 따라서 관리자는 이를 인지하고 어떠한 결과가 발생하기 전에 이를 시정할 것입니다.연약한잠금 문제.
Jul 08 17:24:20 mount[957]: mount.nfs: rpc.statd가 실행되고 있지 않지만 원격 잠금에 필요합니다. Jul 08 17:24:20 mount[957]: mount.nfs: "-o nolock"을 사용하여 잠금을 로컬로 유지하거나 statd를 시작합니다.
https://forums.fedoraforum.org/showthread.php?292563-rpc-statd-starting-after-some-nfs-mounts
반면, 손실은 rpc-statd-notify쉽게 간과되므로 서버에 지속적으로 바람직하지 않은 영향(부실 잠금)이 발생할 수 있습니다. 그렇다면 활성화되도록 장려하는 것이 있으면 좋을 것 같습니다 ...
더 이상 NFSv3 시작에 대한 공식 Redhat 문서가 많지 않은 것 같습니다(그리고 Google도 마찬가지입니다).훌륭한도 도움이 됩니다). 오래된 문서에는 전통적으로 여러 서비스 활성화가 포함되어 있으며 rpc.statd 데몬이 그 일부로 언급되는 경향이 있습니다.
그러나 나는 이러한 불일치가 사람들이 여전히 rpc-statd를 활성화하고 rpc-statd-notify 활성화의 필요성을 무시할 가능성이 있다는 것을 의미한다고 생각합니다. 특히 rpc-statd를 시작하는 서비스가 비트 자체에 대한 알림을 완료한 것으로 보이는 초기 단계부터 rpc-statd.service가 설정되는 것을 볼 수 있습니다 RPC_STATD_NO_NOTIFY=1.
따라서 nfs-client.target자동으로 시작되지 않고 이를 활성화할 서비스 중 하나로 언급하는 문서가 없다면 위의 근거는 허술해 보입니다. 아마도 더 나은 설명은 그것이 단지 낡고, 방치되고, 어수선하다는 것입니다.
하지만 이 역시 별로 신뢰할 만한 답변은 아닌 것 같습니다. 어떤 순간에는 반드시 특별한 이유가 있을 것이다아니요rpc.statd가 알림 부분 자체를 수행하도록 하세요.
참고: sm-notify 명령에는 시스템을 다시 시작할 때마다 한 번만 실행되는지 확인하는 검사가 포함되어 있습니다. 이는 [--no-notify] 옵션 없이 rpc.statd가 다시 시작되는 경우 가짜 다시 시작 알림을 방지합니다.