sm-notify: Use my_name when sending SM_NOTIFY requests
[nfs-utils.git] / utils / statd / sm-notify.man
1 .\"@(#)sm-notify.8"
2 .\"
3 .\" Copyright (C) 2004 Olaf Kirch <okir@suse.de>
4 .\"
5 .\" Rewritten by Chuck Lever <chuck.lever@oracle.com>, 2009.
6 .\" Copyright 2009 Oracle.  All rights reserved.
7 .\"
8 .TH SM-NOTIFY 8 "1 November 2009
9 .SH NAME
10 sm-notify \- send reboot notifications to NFS peers
11 .SH SYNOPSIS
12 .BI "/usr/sbin/sm-notify [-dfn] [-m " minutes "] [-v " name "] [-p " notify-port "] [-P " path "]
13 .SH DESCRIPTION
14 File locks are not part of persistent file system state.
15 Lock state is thus lost when a host reboots.
16 .PP
17 Network file systems must also detect when lock state is lost
18 because a remote host has rebooted.
19 After an NFS client reboots, an NFS server must release all file locks
20 held by applications that were running on that client.
21 After a server reboots, a client must remind the
22 server of file locks held by applications running on that client.
23 .PP
24 For NFS version 2 and version 3, the
25 .I Network Status Monitor
26 protocol (or NSM for short)
27 is used to notify NFS peers of reboots.
28 On Linux, two separate user-space components constitute the NSM service:
29 .TP
30 .B sm-notify
31 A helper program that notifies NFS peers after the local system reboots
32 .TP
33 .B rpc.statd
34 A daemon that listens for reboot notifications from other hosts, and
35 manages the list of hosts to be notified when the local system reboots
36 .PP
37 The local NFS lock manager alerts its local
38 .B rpc.statd
39 of each remote peer that should be monitored.
40 When the local system reboots, the
41 .B sm-notify
42 command notifies the NSM service on monitored peers of the reboot.
43 When a remote reboots, that peer notifies the local
44 .BR rpc.statd ,
45 which in turn passes the reboot notification
46 back to the local NFS lock manager.
47 .SH NSM OPERATION IN DETAIL
48 The first file locking interaction between an NFS client and server causes
49 the NFS lock managers on both peers to contact their local NSM service to
50 store information about the opposite peer.
51 On Linux, the local lock manager contacts
52 .BR rpc.statd .
53 .PP
54 .B rpc.statd
55 records information about each monitored NFS peer on persistent storage.
56 This information describes how to contact a remote peer
57 in case the local system reboots,
58 how to recognize which monitored peer is reporting a reboot,
59 and how to notify the local lock manager when a monitored peer
60 indicates it has rebooted.
61 .PP
62 An NFS client sends a hostname, known as the client's
63 .IR caller_name ,
64 in each file lock request.
65 An NFS server can use this hostname to send asynchronous GRANT
66 calls to a client, or to notify the client it has rebooted.
67 .PP
68 The Linux NFS server can provide the client's
69 .I caller_name
70 or the client's network address to
71 .BR rpc.statd .
72 For the purposes of the NSM protocol,
73 this name or address is known as the monitored peer's
74 .IR mon_name .
75 In addition, the local lock manager tells
76 .B rpc.statd
77 what it thinks its own hostname is.
78 For the purposes of the NSM protocol,
79 this hostname is known as
80 .IR my_name .
81 .PP
82 There is no equivalent interaction between an NFS server and a client
83 to inform the client of the server's
84 .IR caller_name .
85 Therefore NFS clients do not actually know what
86 .I mon_name
87 an NFS server might use in an SM_NOTIFY request.
88 The Linux NFS client records the server's hostname used on the mount command
89 to identify rebooting NFS servers.
90 .SS Reboot notification
91 When the local system reboots, the
92 .B sm-notify
93 command reads the list of monitored peers from persistent storage and
94 sends an SM_NOTIFY request to the NSM service on each listed remote peer.
95 It uses the
96 .I mon_name
97 string as the destination.
98 To identify which host has rebooted, the
99 .B sm-notify
100 command normally sends
101 .I my_name
102 string recorded when that remote was monitored.
103 The remote
104 .B rpc.statd
105 matches incoming SM_NOTIFY requests using this string,
106 or the caller's network address,
107 to one or more peers on its own monitor list.
108 .PP
109 If
110 .B rpc.statd
111 does not find a peer on its monitor list that matches
112 an incoming SM_NOTIFY request,
113 the notification is not forwarded to the local lock manager.
114 In addition, each peer has its own
115 .IR "NSM state number" ,
116 a 32-bit integer that is bumped after each reboot by the
117 .B sm-notify
118 command.
119 .B rpc.statd
120 uses this number to distinguish between actual reboots
121 and replayed notifications.
122 .PP
123 Part of NFS lock recovery is rediscovering
124 which peers need to be monitored again.
125 The
126 .B sm-notify
127 command clears the monitor list on persistent storage after each reboot.
128 .SH OPTIONS
129 .TP
130 .B -d
131 Keeps
132 .B sm-notify
133 attached to its controlling terminal and running in the foreground
134 so that notification progress may be monitored directly.
135 .TP
136 .B -f
137 Send notifications even if
138 .B sm-notify
139 has already run since the last system reboot.
140 .TP
141 .BI -m " retry-time
142 Specifies the length of time, in minutes, to continue retrying
143 notifications to unresponsive hosts.
144 If this option is not specified,
145 .B sm-notify
146 attempts to send notifications for 15 minutes.
147 Specifying a value of 0 causes
148 .B sm-notify
149 to continue sending notifications to unresponsive peers
150 until it is manually killed.
151 .IP
152 Notifications are retried if sending fails,
153 the remote does not respond,
154 the remote's NSM service is not registered,
155 or if there is a DNS failure
156 which prevents the remote's
157 .I mon_name
158 from being resolved to an address.
159 .IP
160 Hosts are not removed from the notification list until a valid
161 reply has been received.
162 However, the SM_NOTIFY procedure has a void result.
163 There is no way for
164 .B sm-notify
165 to tell if the remote recognized the sender and has started
166 appropriate lock recovery.
167 .TP
168 .B -n
169 Prevents
170 .B sm-notify
171 from updating the local system's NSM state number.
172 .TP
173 .BI -p " port
174 Specifies the source port number
175 .B sm-notify
176 should use when sending reboot notifications.
177 If this option is not specified, a randomly chosen ephemeral port is used.
178 .IP
179 This option can be used to traverse a firewall between client and server.
180 .TP
181 .BI "\-P, " "" \-\-state\-directory\-path " pathname
182 Specifies the pathname of the parent directory
183 where NSM state information resides.
184 If this option is not specified,
185 .B sm-notify
186 uses
187 .I /var/lib/nfs
188 by default.
189 .IP
190 After starting,
191 .B sm-notify
192 attempts to set its effective UID and GID to the owner
193 and group of this directory.
194 .TP
195 .BI -v " ipaddr " | " hostname
196 Specifies the network address from which to send reboot notifications,
197 and the
198 .I mon_name
199 argument to use when sending SM_NOTIFY requests.
200 If this option is not specified,
201 .B sm-notify
202 uses a wildcard address as the transport bind address,
203 and uses the
204 .I my_name
205 recorded when the remote was monitored as the
206 .I mon_name
207 argument when sending SM_NOTIFY requests.
208 .IP
209 The
210 .I ipaddr
211 form can be expressed as either an IPv4 or an IPv6 presentation address.
212 If the
213 .I ipaddr
214 form is used, the
215 .B sm-notify
216 command converts this address to a hostname for use as the
217 .I mon_name
218 argument when sending SM_NOTIFY requests.
219 .IP
220 This option can be useful in multi-homed configurations where
221 the remote requires notification from a specific network address.
222 .SH SECURITY
223 The
224 .B sm-notify
225 command must be started as root to acquire privileges needed
226 to access the state information database.
227 It drops root privileges
228 as soon as it starts up to reduce the risk of a privilege escalation attack.
229 .PP
230 During normal operation,
231 the effective user ID it chooses is the owner of the state directory.
232 This allows it to continue to access files in that directory after it
233 has dropped its root privileges.
234 To control which user ID
235 .B rpc.statd
236 chooses, simply use
237 .BR chown (1)
238 to set the owner of
239 the state directory.
240 .SH ADDITIONAL NOTES
241 Lock recovery after a reboot is critical to maintaining data integrity
242 and preventing unnecessary application hangs.
243 .PP
244 To help
245 .B rpc.statd
246 match SM_NOTIFY requests to NLM requests, a number of best practices
247 should be observed, including:
248 .IP
249 The UTS nodename of your systems should match the DNS names that NFS
250 peers use to contact them
251 .IP
252 The UTS nodenames of your systems should always be fully qualified domain names
253 .IP
254 The forward and reverse DNS mapping of the UTS nodenames should be
255 consistent
256 .IP
257 The hostname the client uses to mount the server should match the server's
258 .I mon_name
259 in SM_NOTIFY requests it sends
260 .PP
261 Unmounting an NFS file system does not necessarily stop
262 either the NFS client or server from monitoring each other.
263 Both may continue monitoring each other for a time in case subsequent
264 NFS traffic between the two results in fresh mounts and additional
265 file locking.
266 .PP
267 On Linux, if the
268 .B lockd
269 kernel module is unloaded during normal operation,
270 all remote NFS peers are unmonitored.
271 This can happen on an NFS client, for example,
272 if an automounter removes all NFS mount
273 points due to inactivity.
274 .SS IPv6 and TI-RPC support
275 TI-RPC is a pre-requisite for supporting NFS on IPv6.
276 If TI-RPC support is built into the
277 .B sm-notify
278 command ,it will choose an appropriate IPv4 or IPv6 transport
279 based on the network address returned by DNS for each remote peer.
280 It should be fully compatible with remote systems
281 that do not support TI-RPC or IPv6.
282 .PP
283 Currently, the
284 .B sm-notify
285 command supports sending notification only via datagram transport protocols.
286 .SH FILES
287 .TP 2.5i
288 .I /var/lib/nfs/sm
289 directory containing monitor list
290 .TP 2.5i
291 .I /var/lib/nfs/sm.bak
292 directory containing notify list
293 .TP 2.5i
294 .I /var/lib/nfs/state
295 NSM state number for this host
296 .TP 2.5i
297 .I /proc/sys/fs/nfs/nsm_local_state
298 kernel's copy of the NSM state number
299 .SH SEE ALSO
300 .BR rpc.statd (8),
301 .BR nfs (5),
302 .BR uname (2),
303 .BR hostname (7)
304 .PP
305 RFC 1094 - "NFS: Network File System Protocol Specification"
306 .br
307 RFC 1813 - "NFS Version 3 Protocol Specification"
308 .br
309 OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11
310 .SH AUTHORS
311 Olaf Kirch <okir@suse.de>
312 .br
313 Chuck Lever <chuck.lever@oracle.com>