NAME<\/a> sm-notify \u2212 send reboot notifications to NFS peers<\/p>\n \/usr\/sbin\/sm-notify [-dfn] [-m<\/b> minutes<\/i>] [-v<\/b> name<\/i>] [-p<\/b> notify-port<\/i>] [-P<\/b> path<\/i>]<\/b><\/p>\n File locks are not part of persistent file system state. Lock state is thus lost when a host reboots.<\/p>\n 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.<\/p>\n For NFS version 2 and version 3, the Network Status Monitor<\/i> protocol (or NSM for short) is used to notify NFS peers of reboots. On Linux, two separate user-space components constitute the NSM service: A helper program that notifies NFS peers after the local system reboots<\/p>\n rpc.statd<\/b><\/p>\n A daemon that listens for reboot notifications from other hosts, and manages the list of hosts to be notified when the local system reboots<\/p>\n The local NFS lock manager alerts its local rpc.statd<\/b> of each remote peer that should be monitored. When the local system reboots, the sm-notify<\/b> command notifies the NSM service on monitored peers of the reboot. When a remote reboots, that peer notifies the local rpc.statd<\/b>, which in turn passes the reboot notification back to the local NFS lock manager.<\/p>\n The first file locking interaction between an NFS client and server causes the NFS lock managers on both peers to contact their local NSM service to store information about the opposite peer. On Linux, the local lock manager contacts rpc.statd<\/b>.<\/p>\n rpc.statd<\/b> records information about each monitored NFS peer on persistent storage. This information describes how to contact a remote peer in case the local system reboots, how to recognize which monitored peer is reporting a reboot, and how to notify the local lock manager when a monitored peer indicates it has rebooted.<\/p>\n An NFS client sends a hostname, known as the client\u2019s caller_name<\/i>, in each file lock request. An NFS server can use this hostname to send asynchronous GRANT calls to a client, or to notify the client it has rebooted.<\/p>\n The Linux NFS server can provide the client\u2019s caller_name<\/i> or the client\u2019s network address to rpc.statd<\/b>. For the purposes of the NSM protocol, this name or address is known as the monitored peer\u2019s mon_name<\/i>. In addition, the local lock manager tells rpc.statd<\/b> what it thinks its own hostname is. For the purposes of the NSM protocol, this hostname is known as my_name<\/i>.<\/p>\n There is no equivalent interaction between an NFS server and a client to inform the client of the server\u2019s caller_name<\/i>. Therefore NFS clients do not actually know what mon_name<\/i> an NFS server might use in an SM_NOTIFY request. The Linux NFS client records the server\u2019s hostname used on the mount command to identify rebooting NFS servers.<\/p>\n Reboot notification<\/b> If rpc.statd<\/b> does not find a peer on its monitor list that matches an incoming SM_NOTIFY request, the notification is not forwarded to the local lock manager. In addition, each peer has its own NSM state number<\/i>, a 32-bit integer that is bumped after each reboot by the sm-notify<\/b> command. rpc.statd<\/b> uses this number to distinguish between actual reboots and replayed notifications.<\/p>\n Part of NFS lock recovery is rediscovering which peers need to be monitored again. The sm-notify<\/b> command clears the monitor list on persistent storage after each reboot.<\/p>\n
SYNOPSIS<\/a>
DESCRIPTION<\/a>
NSM OPERATION IN DETAIL<\/a>
OPTIONS<\/a>
CONFIGURATION FILE<\/a>
SECURITY<\/a>
ADDITIONAL NOTES<\/a>
FILES<\/a>
SEE ALSO<\/a>
AUTHORS<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
DESCRIPTION <\/a> <\/h2>\n
sm-notify<\/b><\/p>\nNSM OPERATION IN DETAIL <\/a> <\/h2>\n
When the local system reboots, the sm-notify<\/b> command reads the list of monitored peers from persistent storage and sends an SM_NOTIFY request to the NSM service on each listed remote peer. It uses the mon_name<\/i> string as the destination. To identify which host has rebooted, the sm-notify<\/b> command normally sends my_name<\/i> string recorded when that remote was monitored. The remote rpc.statd<\/b> matches incoming SM_NOTIFY requests using this string, or the caller\u2019s network address, to one or more peers on its own monitor list.<\/p>\nOPTIONS <\/a> <\/h2>\n