NAME<\/a> rpc.statd \u2212 NSM service daemon<\/p>\n rpc.statd [-dh?FLNvV] [-H<\/b> prog<\/i>] [-n<\/b> my-name<\/i>] [-o<\/b> outgoing-port<\/i>] 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 [RFC1094] and NFS version 3 [RFC1813], 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 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 sm-notify<\/b><\/p>\n A helper program that notifies NFS peers after 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 uses the server hostname from 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 -d<\/b>, –no-syslog<\/b><\/p>\n Causes rpc.statd<\/b> to write log messages on stderr<\/i> instead of to the system log, if the -F<\/b> option was also specified.<\/p>\n -F<\/b>, –foreground<\/b><\/p>\n Keeps rpc.statd<\/b> attached to its controlling terminal so that NSM operation can be monitored directly or run under a debugger. If this option is not specified, rpc.statd<\/b> backgrounds itself soon after it starts.<\/p>\n -h<\/b>, -?<\/b>, –help<\/b><\/p>\n Causes rpc.statd<\/b> to display usage information on stderr<\/i> and then exit.<\/p>\n \u2212H, \u2212\u2212ha-callout<\/b> prog<\/i><\/p>\n Specifies a high availability callout program. If this option is not specified, no callouts are performed. See the High-availability callouts<\/b> section below for details.<\/p>\n -L<\/b>, –no-notify<\/b><\/p>\n Prevents rpc.statd<\/b> from running the sm-notify<\/b> command when it starts up, preserving the existing NSM state number and monitor list.<\/p>\n Note: the sm-notify<\/b> command contains a check to ensure it runs only once after each system reboot. This prevents spurious reboot notification if rpc.statd<\/b> restarts without the -L<\/b> option.<\/p>\n \u2212n, \u2212\u2212name<\/b> ipaddr<\/i> |<\/b> hostname<\/i><\/p>\n This string is only used by the sm-notify<\/b> command as the source address from which to send reboot notification requests.<\/p>\n The ipaddr<\/i> form can be expressed as either an IPv4 or an IPv6 presentation address. If this option is not specified, rpc.statd<\/b> uses a wildcard address as the transport bind address. See sm-notify<\/b>(8) for details.<\/p>\n
SYNOPSIS<\/a>
DESCRIPTION<\/a>
NSM OPERATION IN DETAIL<\/a>
OPTIONS<\/a>
CONFIGURATION FILE<\/a>
SECURITY<\/a>
ADDITIONAL NOTES<\/a>
ENVIRONMENT<\/a>
FILES<\/a>
SEE ALSO<\/a>
AUTHORS<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
[-p<\/b> listener-port<\/i>] [-P<\/b> path<\/i>]
[–nlm-port<\/b> port<\/i>] [–nlm-udp-port<\/b> port<\/i>]<\/b><\/p>\nDESCRIPTION <\/a> <\/h2>\n
rpc.statd<\/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 sends the 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