 |
» |
|
|
|
If ntp is not operating properly, use this section to
identify and correct the problem. To Find Out if xntpd is Running | |
Issue the following command to find out if xntpd is running: /usr/bin/ps -ef | /usr/bin/grep xntpd |
This command reports the process identification (PID), current
time, and the command invoked (xntpd). An example output is shown below: daemon 4484 1 0 Feb 18 0:00 xntpd
user 3691 2396 2 15:08:45 0:00 grep xntp |
Ensure syslogd is configured to log daemon information messages
to the file /var/adm/syslog/syslog.log. To check this configuration, make sure /etc/syslog.conf includes one of the following lines: *.info /var/adm/syslog/syslog.log |
or daemon.info /var/adm/syslog/syslog.log |
If xntpd is not running, check the syslog file for related messages. NTP Associations | |
Each NTP daemon must form an association with a time source:
a higher-level (lower stratum) server or, for stratum-1 servers,
an external clock. NTP daemons may form additional associations
with peer servers. To list the NTP associations the local NTP daemon
has established, use the command: Note that in the output an asterisk (*) must appear next to the node name to indicate
that an association has been formed. In the example below, the local NTP daemon has established
an association with the NTP daemon on node good.cup.hp, but not with the node bad: Table 7-8 ntpg Output Showing NTP Associations remote refid st when poll reach delay offset disp
===========================================================================
*good.cup.hp LOCAL(1) 2 29 64 377 5.43 -0.16 16.40
bad 0.0.0.0 - 31 64 0 |
|
If the local node cannot form an association with its higher-level
server or its peer, log in to the higher-level server or peer and
issue the command: Verify that the higher-level server/peer has itself established
an association with a time source. Query with Debug Option | |
If you cannot form an association with a server or peer, stop
the local xntpd and send a time request to the server/peer with
the ntpdate command and the debug (-d) option: /sbin/init.d/xntpd stop
/usr/sbin/ntpdate -d server |
The debug (-d) option prints information about the requests
sent to the remote xntpd and the information returned by the remote xntpd. Note that ntpdate will fail if xntpd is already running on the local system. Note also that ntpdate does not use authentication, so it should only
be executable by root. You can also use ntpdate on systems where exact time synchronization is
not necessary. You could run ntpdate periodically from cron every hour or two to synchronize the local clock
to another system's clock. Refer to the ntpdate(1M) man page for more information. Error Messages | |
This section describes a few error messages you may encounter
when working with NTP. No Server Suitable for synchronization found.This message indicates that the NTP server is not responding
for some reason. Packets were sent out, but no reply was returned.
Perhaps the server is down, or the network link is broken or extremely
congested. Or perhaps the NTP daemon died on the server and has
not yet locked on to its time sources. NTP version 3.5 and above
take between 5 and 15 minutes after starting up the daemon to synchronize,
and it will not respond to client requests during this time. Last adjustment did not complete.This message means that NTP is trying to make many adjustment bigger
than the system's maximum slew rate allows in one clock
tick. So the remainder of the adjustments is pushed to the next
clock tick. This is handled automatically. You will often see this
message in the first hour after the NTP daemon is started. If you
continue to see it after a few days of steady operation, then your
system clock is probably drifting causing you to lose contact with
your network time servers. This message indicates that NTP has cleared all of the statistics registers
and has started evaluating all available time servers and choosing
the "best" one. This message appears whenever
a step adjustment (greater than 128 milliseconds) is made, since
the step leaves the system unsynchronized by definition. If your
system is making a lot of step adjustments, it probably means that
you have network congestion problems. To review this, do the following: Run ntpq -p Examine the dispersion statistics.
Common Problems | |
This section covers typical problems with ntp operation. Problem 1: No suitable server for synchronization
found.Every NTP time hierarchy must have at least one stratum-1
server, with an external time source configured, either an attached
radio clock (Netclock/2 WWVB Synchronized Clock) or the local system
clock. If there is no stratum-1 server in the hierarchy, no associations
will be formed. To verify that the local xntpd is able to form an association, issue the command: The server is the name of a trusted server, such as a peer
or higher-level (lower stratum) server. If the local xntpd is unable to form any associations, this command
will return the message "No suitable server for synchronization
found." Check the sections below for possible causes. Time Difference Greater than 1000 secondsWhen evaluating incoming time updates, clients and peers reject
time from servers/peers if the time difference is 1000 seconds or
greater. On a non-broadcast client or peer, the xntpd daemon will eventually die if it cannot find a
suitable server after six consecutive polls, or five polling cycles
(approximately 320 seconds if using the default polling interval). Because of this behavior, you may have to issue the following
command to synchronize the local system time with another NTP server
before starting xntpd: For HP-UX NFS Diskless Clusters, the /sbin/init.d/xntpd script on the diskless clients will execute xntpdate to synchronize time with the diskless cluster
server before starting xntpd. You can also explicitly specify a trusted time server in /etc/rc.config.d/netdaemons, and /sbin/init.d/xntpd will execute xntpdate, querying the specified time server. When xntpd first starts, it takes five poll cycles (320 seconds
using the default polling interval) to form an association with
a higher-level server or peer. During this time window, xntpd will not respond to time requests from other NTP
systems, since it does not have a suitable time source. This window
exists even if xntpd is using an external clock, which can be either
an attached radio clock (Netclock/2 WWVB Synchronized Clock) or
the local system clock (server 127.127.n.n). For external clocks, xntpd will not form a complete association until it has
sent five successful polls to itself using the local loopback address. Problem 2: Version 1 and 2 NTP Servers Do Not RespondNTP version 3 packets (HP-UX 10.0 NTP is version 3) are ignored
by NTP version 1 and version 2 systems. The solution is to indicate
the version 1 and 2 systems in the configuration entries on the
version 3 systems. This will tell the version 3 system to use the
older message formats when communicating with these systems. The following configuration file entries tell xntpd to use NTP version 2 message formats when communicating
with some_ver2.sys and NTP version 1 when communicating with some_ver1.sys. server some_ver2.sys version 2
server some_ver1.sys version 1 |
Reporting Problems | |
Provide the following information when reporting NTP problems: /etc/ntp.conf (or an alternate configuration file, if used) NTP driftfile (if configured) NTP statistics file (if configured) /var/adm/syslog/syslog.log (xntpd/NTP entries) output from /usr/sbin/ntpq -p output from ntpdate -d server (stop the local xntpd first)
|
