3 msntp \- a SNTP utility (command and daemon)
56 can be used as a SNTP client to query a NTP or SNTP server and either display
57 the time or set the local system's time (given suitable privilege). It can be
58 run as an interactive command, in a
60 job or as a daemon. It can be run as a daemon to provide a SNTP server for
61 other clients. NTP is the Network Time Protocol (RFC 1305) and SNTP is the
62 Simple Network Time Protocol (RFC 2030, which supersedes RFC 1769).
66 recognizes the following options:
69 displays the syntax error message. If there are no other arguments, it then
70 stops; otherwise it then does what was requested.
77 indicates that diagnostic messages for non-fatal errors and a limited amount of
78 tracing should be written to standard error. Fatal ones always produce a
79 diagnostic. This option should be set when there is a suspected problem with
80 the server, network or the source.
83 requests more and less comprehensible output, mainly for investigating problems
84 with apparently inconsistent timestamps. This option should be set when the
85 program fails with a message indicating that is the trouble.
88 requests very verbose debugging output, and will interfere with the timing
89 when writing to the terminal (because of line buffered output from C). Note
90 that the times produced by this are the corrections needed, and not the error
91 in the local clock. This option should be set only when debugging the source.
94 indicates that it should behave as a server, broadcasting time packets at
97 minutes (sic). Acceptable values of
99 are from 1 to 1440 (a day), and the default (i.e. if
103 is omitted) is 60. Naturally, this will work only if the user has enough
107 indicates that it should behave as a server, responding to time requests from
108 clients. Naturally, this will work only if the user has enough privilege.
111 indicates that it should query a daemon save file being maintained by it.
112 This needs no privilege and will change neither the save file nor the clock.
114 The default is that it should behave as a client, and the following options
118 indicates that the system clock should be reset by
120 Naturally, this will work only if the user has enough privilege.
123 indicates that the system clock should be reset by
125 Naturally, this will work only if the user has enough privilege.
127 The default is to write the estimated correct local date and time (i.e. not
128 UTC) to the standard output in a format like
129 .BR "'1996 Oct 15 20:17:25.123 + 4.567 +/- 0.089 secs'" ,
131 .B "'+ 4.567 +/- 0.089 secs'"
132 indicates the estimated error in the time on the local system. In daemon mode,
133 it will add drift information in a format like
134 .BR "' + 1.3 +/- 0.1 ppm'" ,
135 and display this at roughly
137 intervals (see under the
142 sets the name of the lock file to ensure that there is only
145 running at once. The default is installation-dependent, but will usually be
149 sets the maximum ignorable variation between the clocks to
151 Acceptable values are from 0.001 to 1, and the default is 0.1 if a NTP host is
152 is specified and 0.5 otherwise.
155 sets the maximum value of various delays that are deemed acceptable to
157 Acceptable values are from 1 to 60, and the default is 5. It should sometimes
158 be increased if there are problems with the network, NTP server or system
159 clock, but take care.
162 sets the maximum clock change that will be made automatically to
164 Acceptable values are from 1 to 3600 or
166 and the default is 30. If the program is being run interactively in ordinary
167 client mode, and the system clock is to be changed, larger corrections will
168 prompt the user for confirmation. Specifying
170 will disable this and the correction will be made regardless.
173 sets the maximum number of NTP packets required to
175 Acceptable values are from 1 to 25 if a NTP host is specified and from 5 to 25
176 otherwise, and the default is 5. If the maximum isn't enough, the system needs
177 a better consistency algorithm than this program uses.
180 sets a rough limit on the total running time to
182 seconds. Acceptable values are from 1 to 3600, and the default is 15 if a NTP
183 host is specified and 300 otherwise.
185 .BI \-x " separation"
186 causes the program to run as a daemon (i.e. forever), and to estimate and
187 correct for the clock drift.
189 sets the minimum time between calls to the server in minutes if a NTP host is
190 specified, and between broadcast packets if not. Acceptable values are from 1
191 to 1440 (a day), and the default (if
200 option to store a record of previous packets, which speeds up recalculating
203 has to be restarted (e.g. because of network or server outages). In order to
206 must be restarted reasonably soon after it died (within a few times the value of
208 with the same value of the
210 option, the same value of
212 in the same mode (i.e. broadcast or client), though the NTP servers need not
213 be the same for client mode, and with compatible values of other settings.
214 Note that the file will be created with the default ownerships and permissions,
215 using standard C facilities. The default is installation-dependent, but will
217 .IR /etc/msntp.state .
220 are the DNS names or IP numbers of hosts to use for the challenge and response
221 protocol; if no names are given, the program waits for broadcasts. Polling a
222 server is vastly more reliable than listening to broadcasts. Note that a
223 single component numeric address is not allowed, to avoid ambiguities. If
224 more than one name is give, they will be used in a round-robin fashion.
231 which must be less than
233 (or, if a NTP host is not specified
234 .BR delay / count "),"
237 must be less than half of
245 In daemon mode (i.e. when
251 which must be less than
253 (note that this is in minutes, not seconds, but the numeric value is compared).
255 Note that none of the above values are closely linked to the limits described
256 in the NTP protocol (RFC 1305).
258 The simplest use of this program is as an unprivileged command to check the
259 current time and error in the local clock. For example:
261 .B msntp ntpserver.somewhere
263 It can be run as a unprivileged background process to check on the clock drift
264 as well as the current error; this will probably fail if the local clock is
265 reset while it is running. For example:
267 .B msntp -x ntpserver.somewhere > output 2>\&1 \&
269 With suitable privilege, it can be run as a command or in a
271 job to reset the local clock from a reliable server, like the
275 commands. For example:
277 .B msntp -a ntpserver.somewhere
279 It can also be run as a daemon to keep the local clock in step. For example:
281 .B msntp -a -x ntpserver.somewhere > output 2>\&1 \&
283 More information on how to use this utility is given in the
285 file in the distribution. In particular, this
287 page does not describe how to set it up as a server, which needs special care
288 to avoid propagating misinformation.
290 When used as a client in non-daemon mode, the program returns a zero exit
291 status for success, and a non-zero one otherwise. When used as a daemon
292 (either client or server), it does not return except after a serious error.
294 The program implements the SNTP protocol, and does not provide all NTP
295 facilities. In particular, it contains no checks against any form of spoofing.
296 If this is a serious concern, some network security mechanism (like a firewall
301 There are some errors, ambiguities and inconsistencies in the RFCs, and this
302 code may not interwork with all other NTP implementations. Any unreasonable
303 restrictions should be reported as bugs to whoever is responsible. It may
304 be difficult to find out who that is.
306 The program will stop as soon as it feels that things have got out of control.
307 In client daemon mode, it will usually fail during an extended period of
308 network or server inaccessibility or excessively slow performance, or when the
309 local clock is reset by another process. It will then need restarting
310 manually. Experienced system administrators can write a shell script, a
314 to do this automatically.
316 The error cannot be estimated reliably with broadcast packets or for the drift
317 in daemon mode (even with client-server packets), and the guess made by the
318 program may be wrong (possibly even very wrong). If this is a problem, then
321 option to a larger value may help. Or it may not.
324 was developed by N.M. Maclaren of the University of Cambridge Computing
OSDN Git Service
