# NTPD problems

## JoHauke

Every time I update to the latest version of NTP my NTPD breaks.  Usually I play around with a couple of config files and things start working again, but I can't get it to work after the latest update (4.2.2).  Restarting ntp-client syncs my clock but NTPD doesn't keep it in sync.  What am I doing wrong?

```
#more /etc/ntp.conf

# Generated by dhcpcd for interface eth0

#restrict default noquery notrust nomodify

restrict 127.0.0.1 nomodify noquery

# restrict 24.26.163.31 nomodify notrap noquery

#server 192.43.244.18

server pool.ntp.org

driftfile /var/lib/ntp/ntp.drift

logfile /var/log/ntp.log
```

                                                     NOTE: This file is where I play with things the most.  I don't remember what the original was anymore.

```
# more /var/log/ntp.log

24 Sep 10:36:04 ntpd[2423]: ntpd exiting on signal 15

24 Sep 10:20:16 ntpd[5314]: ntpd exiting on signal 15

24 Sep 10:45:53 ntpd[5536]: ntpd exiting on signal 15

24 Sep 10:46:10 ntpd[5746]: ntpd exiting on signal 15

24 Sep 10:46:39 ntpd[5862]: ntpd exiting on signal 15
```

----------

## wynn

Your ntp.conf is overwritten by dhcpcd every time the NIC is brought up, it might be better to add

```
dhcp_eth0="nontp"
```

 to your /etc/conf.d/net and use a fixed one. This configuration file has been used for a long time with no problems

```
server 0.uk.pool.ntp.org

server 1.uk.pool.ntp.org

server 2.uk.pool.ntp.org

driftfile       /var/lib/ntp/ntp.drift

restrict default nomodify nopeer

restrict 127.0.0.1
```

You will want to replace "uk" by your appropriate letters. Having more that one server is protection against a server which is out of business for some reason.

Just plain ntpd is used here: /etc/init.d/ntpd and 

```
# rc-update show

                ntpd |      default
```

Your log output looks strange, you should get something like

```
Sep 24 14:49:24 lightfoot ntpd[8354]: ntpd 4.2.2p3@1.1577-o Sun Sep 10 09:57:05 UTC 2006 (1)

Sep 24 14:49:24 lightfoot ntpd[8355]: precision = 1.000 usec

Sep 24 14:49:24 lightfoot ntpd[8355]: Listening on interface wildcard, 0.0.0.0#123 Disabled

Sep 24 14:49:24 lightfoot ntpd[8355]: Listening on interface lo, 127.0.0.1#123 Enabled

Sep 24 14:49:24 lightfoot ntpd[8355]: Listening on interface eth0, 192.168.1.37#123 Enabled

Sep 24 14:49:24 lightfoot ntpd[8355]: Listening on interface ath0, 192.168.0.100#123 Enabled

Sep 24 14:49:24 lightfoot ntpd[8355]: kernel time sync status 0040

Sep 24 14:49:24 lightfoot ntpd[8355]: frequency initialized 77.393 PPM from /var/lib/ntp/ntp.drift
```

every time ntpd starts.

There is a comment at the top of ntp.conf

```
#  - if you start getting lines like 'restrict' and 'fudge'

#    and you didnt add them, AND you run dhcpcd on your

#    network interfaces, be sure to add '-Y -N' to the

#    dhcpcd_ethX variables in /etc/conf.d/net
```

which might be of interest.

----------

## JoHauke

According to the gentoo wiki I am supposed to add the -N option to my /etc/conf.d/net file instead of the "nontp" you mention (I am running dhcpcd not dhclient).  I also tried adding the -Y option you mention but no difference that I can see.  

I do get lines similar to what you say if I look at /var/log/messages

```
Sep 24 12:55:45 localhost ntpd[10122]: ntpd 4.2.2p3@1.1577-o Sat Sep 16 18:36:30 UTC 2006 (1)

Sep 24 12:55:45 localhost ntpd[10123]: precision = 1.000 usec

Sep 24 12:55:45 localhost ntpd[10123]: Listening on interface wildcard, 0.0.0.0#123 Disabled

Sep 24 12:55:45 localhost ntpd[10123]: Listening on interface lo, 127.0.0.1#123 Enabled

Sep 24 12:55:45 localhost ntpd[10123]: Listening on interface eth0, 192.168.10.2#123 Enabled

Sep 24 12:55:45 localhost ntpd[10123]: Listening on interface eth1, 192.168.10.5#123 Enabled

Sep 24 12:55:45 localhost ntpd[10123]: kernel time sync status 0040

Sep 24 12:55:45 localhost ntpd[10123]: frequency initialized -18.899 PPM from /var/lib/ntp/ntp.drift

Sep 24 13:01:08 localhost ntpd[10753]: ntpd 4.2.2p3@1.1577-o Sat Sep 16 18:36:30 UTC 2006 (1)

Sep 24 13:01:08 localhost ntpd[10754]: precision = 1.000 usec

Sep 24 13:01:08 localhost ntpd[10754]: bind() fd 16, family 2, port 123, addr 0.0.0.0, in_classd=0 flags=9 fails: Address already in use

Sep 24 13:01:08 localhost ntpd[10754]: bind() fd 16, family 2, port 123, addr 127.0.0.1, in_classd=0 flags=5 fails: Address already in use

Sep 24 13:01:08 localhost ntpd[10754]: bind() fd 16, family 2, port 123, addr 192.168.10.2, in_classd=0 flags=25 fails: Address already in use

Sep 24 13:01:08 localhost ntpd[10754]: bind() fd 16, family 2, port 123, addr 192.168.10.5, in_classd=0 flags=25 fails: Address already in use

Sep 24 13:01:08 localhost ntpd[10754]: kernel time sync status 0040

Sep 24 13:01:08 localhost ntpd[10754]: frequency initialized -18.899 PPM from /var/lib/ntp/ntp.drift
```

The last few lines are the first time I've seen that.

Here's my updated /etc/ntp.conf

```
# cat /etc/ntp.conf

# Generated by dhcpcd for interface eth0

#restrict default noquery notrust nomodify

restrict default nomodify nopeer

restrict 127.0.0.1

# restrict 24.26.163.31 nomodify notrap noquery

#server 192.43.244.18

server pool.ntp.org

server 0.us.ntp.org

server 1.us.ntp.org

server 2.us.ntp.org

driftfile /var/lib/ntp/ntp.drift

logfile /var/log/ntp.log
```

----------

## wynn

 *Quote:*   

> According to the gentoo wiki I am supposed to add the -N option to my /etc/conf.d/net file instead of the "nontp" you mention (I am running dhcpcd not dhclient)

 These are either/or. The /etc/conf.d/net.example says

```
# GENERIC DHCP OPTIONS

# Set generic DHCP options like so

#dhcp_eth0="release nodns nontp nonis nogateway nosendhost"

# This tells the dhcp client to release it's lease when it stops, not to

# overwrite dns, ntp and nis settings, not to set a default route and not to

# send the current hostname to the dhcp server and when it starts.

# You can use any combination of the above options - the default is not to

# use any of them.

```

The different DHCP clients,  dhclient, dhcpcd, pump and udhcpc, have different arguments for the same purpose. The generic options allow you to "set & forget", no change is needed if you decide to use one of the other clients.

For dhcpcd

```
-Y     Prevents  dhcpcd  from replacing existing <etcDir>/yp.conf file.

       Domainname is not updated unless -D is specified.

-N     Prevents dhcpcd from replacing existing <etcDir>/ntp.conf  file.
```

the equivalent of "nonis" and "nontp".

The "Address already in use" sounds as if you have two ntp clients running, one has grabbed the ports leaving ntpd stranded. Did you say you had both ntp-client and ntpd running? Perhaps ntp-client isn't letting go.

You don't need to run ntp-client ("Command to run to set the clock initially") as ntpd will take care of that. If the clock skew is too large for ntpd

```
or for some reason its [RTC clock] time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand. This causes ntpd to exit with a panic message to the system log
```

it will stop.

If you have that degree of clock skew you have other problems.

You might like to check /etc/adjtime for sanity

```
0.000000 1159098576 0.000000

1159098576

UTC
```

The first value is the drift in seconds/day â it should be a small value.

----------

## JoHauke

The wiki says to have ntp-client setup to run on boot:

```
# rc-update show | grep ntp

          ntp-client |      default

                ntpd |      default
```

My /etc/adjtime does seem quite large.  Is this the cause of my problems?

```
# cat /etc/adjtime

2.797954 1159120467 0.000000

1159120467

LOCAL
```

----------

## wynn

I hate to disagree with the wiki which has taught me many good things but, nowadays, running ntpdate is not thought necessary. It was at one time but that was several years ago.

The adjtime may have been set high because ntpd hasn't been able to set your clock properly. Looking at /etc/init.d/clock, it appears to run "hwclock --adjust" which causes hwclock to calculate the drift from the seconds/day and the elapsed time (date is the second value) in adjtime and adjust the clock by this amount.

One other problem is the "LOCAL" setting of your clock (https://bugs.gentoo.org/show_bug.cgi?id=142850) which can cause problems with getting the correct time. 

The only other thing you can do to find out who is hanging on to the 123 ports is

```
netstat -p -l|grep ntp

udp        0      0 192.168.0.100:ntp       *:*                       8355/ntpd

udp        0      0 192.168.1.37:ntp        *:*                       8355/ntpd

udp        0      0 lightfoot.etowers.n:ntp *:*                       8355/ntpd

udp        0      0 *:ntp                   *:*                       8355/ntpd

```

this should show ntpdate (the program actually run by ntp-client) as well as ntpd

----------

## PaulBredbury

 *wynn wrote:*   

> running ntpdate is not thought necessary.

 

Why not? It has a purpose - to correct the time, instantly. Which ntpd will not do.

----------

## JoHauke

Here's the output of the netstat command:

```
# netstat -p -l | grep ntp

udp        0      0 .:ntp                   *:*                                 10124/ntpd

udp        0      0 .:ntp                   *:*                                 10124/ntpd

udp        0      0 localhost:ntp           *:*                                 10124/ntpd

udp        0      0 *:ntp                   *:*                                 10124/ntpd
```

Again, that set of lines from /var/log/messages talking about an address already in use is something I've only seen 1 time.  The set of lines above it is more common.

I use the LOCAL setting b/c I dual boot to winodws.  Niether this nor using the ntp-client has changed since everything worked fine before.

Also, I don't see the hwclock --adjust line in my /etc/init.d/clock

```
# cat /etc/init.d/clock | grep hwclock

        elif [[ -x /sbin/hwclock ]] ; then

                # Since hwclock always exit's with a 0, need to check its output.

                errstr=$(/sbin/hwclock ${myadj} ${myopts} 2>&1 >/dev/null)

                errstr="${errstr}$(/sbin/hwclock --hctosys ${myopts} 2>&1 >/dev/null)"

                errstr="/sbin/hwclock not found"

        elif [[ -x /sbin/hwclock ]] ; then

                errstr=$(/sbin/hwclock --systohc ${myopts} 2>&1 >/dev/null)

                errstr="/sbin/hwclock not found"
```

----------

## wynn

The output from netstat looks OK (i.e. same here)

 *Quote:*   

> Again, that set of lines from /var/log/messages talking about an address already in use is something I've only seen 1 time. The set of lines above it is more common. 

 Then it might have been ntpdate hanging on as it hadn't been able to get a reliable connection. Incidentally, man ntpdate says *Quote:*   

> Disclaimer: The functionality of this program is now available in the ntpd program. See the -q command line option in the ntpd - Network Time Protocol (NTP) daemon page. After a suitable period of mourning, the ntpdate program is to be retired from this distribution

 

 *Quote:*   

> I use the LOCAL setting b/c I dual boot to winodws.

 Yes, I thought so. In this case you probably boot your workstation once a day or thereabouts and the ~2 seconds/day clock drift is neither here nor there. The part of /etc/init.d/clock which sets up the "adjust" is

```
if [[ ${readonly} == "yes" ]] ; then

   myadj="--noadjfile"

else

   myadj="--adjust"

fi
```

and

```
errstr=$(/sbin/hwclock ${myadj} ${myopts} 2>&1 >/dev/null)
```

The problem with the LOCAL setting has nothing to do with ntp and I should have pointed that out: depending on your time zone and the number of hours since the machine was turned off, you can get error messages while booting saying "superblock mount time in the future" which can be ignored as the offending time will be reset by e2fsck and everything will continue running.

PaulBredbury: "Why not? It has a purpose - to correct the time, instantly. Which ntpd will not do."

Well, to split hairs, ntpd can correct the time instantly now, it's part of the decommissioning of ntpdate; from the ntpd manpage *Quote:*   

> In some cases it may not be practical for ntpd to run continuously. A common workaround has been to run the ntpdate program from a cron job at designated times.  However, this program does not have the crafted signal processing, error checking and mitigation algorithms of ntpd .  The -q option is intended for this purpose. Setting this option will cause ntpd to exit just after setting the clock for the first time. The procedure for initially setting the clock is the same as in continuous mode; most applications will probably want to specify the iburst keyword with the server configuration command. With this keyword a volley of messages are exchanged to groom the data and the clock is set in about 10 s. If nothing is heard after a couple of minutes, the daemon times out and exits.

 

But it's a matter of taste: whether you can accept an abrupt change in file times (which, of course, may be just a couple of seconds and thus of no account) or whether you prefer the gradual slew that ntpd does by default.

----------

