# NTPD crashes on start, no idea why.

## KWhat

title says it all /etc/init.d/ntpd[13609]: status: crashed

----------

## gentoo_ram

One possible reason is that if the clock on your computer is "too far" off, then NTP will refuse to change the clock and just shut down.  Make sure your clock is pretty close and the timezone is configured properly.

----------

## NeddySeagoon

KWhat,

Does ntp-client run?

----------

## desultory

 *gentoo_ram wrote:*   

> One possible reason is that if the clock on your computer is "too far" off, then NTP will refuse to change the clock and just shut down.  Make sure your clock is pretty close and the timezone is configured properly.

 In that is the case, invoking ntpdate with the -B option should remedy the problem, though it would potentially take hours to run. Though I suspect something else is wrong in this case.

----------

## KWhat

ntp-client was not setup to start.

----------

## NeddySeagoon

KWhat,

ntp-client runs once and will do a big step change it your clock if needed.  It then hands over to ntpd to keep the time right.

Both should be in the default runlevel.

----------

## Logicien

If you run Systemd and timedatectl is configure to

```
NTP synchronized: yes
```

that can explain why Ntpd do not start. It can be in conflict with systemd-timesyncd.service.

----------

## don quixada

This still doesn't work for me. Do I need to open a port or something? Periodically, my time drifts past 17 mins and stays that way (then ntpd doesn't fix it because it has crashed). After /etc/init.d/ntpd start it fixes the time but then I check the status (/etc/init.d/ntpd status) and it says ntpd has crashed. I'm not sure what to do other than put '/etc/init/ntpd restart' in a cron-job which would fix the problem but I it's not a very elegant solution...

dq

----------

## NeddySeagoon

don quixada,

You could try removing the drift file, then restarting bont ntp-client and ntpcd, in that order.

If your clock is more that 1000 sec out, ntpd will bale out.

Check you can reach an ntp server with 

```
$ ntpq -c rv 192.168.10.3

associd=0 status=01d8 leap_none, sync_pps, 13 events, no_sys_peer,

version="ntpd 4.2.7p364@1.2483-o Fri Apr 12 02:52:48 UTC 2013 (1)",

processor="armv6l", system="Linux/3.6.11-pps-g4642dff-dirty", leap=00,

stratum=1, precision=-19, rootdelay=0.000, rootdisp=1.210, refid=PPS,

reftime=daca203e.3f364003  Tue, Apr 26 2016 18:13:34.246,

clock=daca204d.2efe7a68  Tue, Apr 26 2016 18:13:49.183, peer=63839, tc=4,

mintc=3, offset=-0.003815, frequency=-34.772, sys_jitter=0.001907,

clk_jitter=0.000, clk_wander=0.001
```

That IP address is my time server.    Any response in a good thing.

----------

## don quixada

Ok, I removed the ntp.drift file but it still shows a crashed state after restarting it. Also, it seems to take a long time after issuing the "/etc/init.d/ntp-client restart" command (10 seconds).

Also, something to note, I'm not sure what the drift file contents should typically be but I only had one entry in it (-1.860). Is this normal?

Your ip of the time server is a local ip. Do you have an external one?

dq

----------

## NeddySeagoon

don quixada,

No but any ntp server should respond.

You must run ntp-client before you run ntpd.  The gets your clock correct before ntpd starts.

In turn, that avoids ntpd using the drift to fix your clock over a period of time.

It will give up for errers bigger than 1000 sec. (16.66 mtn)

ntpd should update your BIOS clock regularly too.  That needs kernel support.

After an overnight power off, is the BIOS clock correct?

Maybe you need a new CMOS battery?

----------

## don quixada

Hmm, good question on the battery. The motherboard is only a couple years old but it could be this... I've never had a battery go on me but stranger things have happened.

I will also check the kernel, it is possible that I don't have it enabled. Do you happen to know the flag? 

Regarding the ntp server. I tried to do 'ntpq -c rv 0.ca.pool.ntp.org' but I just got a timeout.

dq

----------

## NeddySeagoon

don quixada,

Search for RTC_LIB, if that is on your system, the following options will be hidden and you are good.

```
  │ │    - - Enhanced Real Time Clock Support (legacy PC RTC driver)              │ │  

  │ │    - - Enhanced Real Time Clock Support                                     │ │  

  │ │    - - Generic /dev/rtc emulation                                           │ │  

  │ │    - -   Extended RTC operation                                             │ │  

  │ │    - - EFI Real Time Clock Services  
```

Otherwise its some combination of the above.

Note the - - means forced off.  To see hidden symbols, press 'z'.  Its a toggle.

----------

## don quixada

Here's what I have:

```
Symbol: RTC_CLASS [=y]                                                 

Type  : boolean                                                        

Prompt: Real Time Clock                                                 

  Location:                                                             

    -> Device Drivers                                                   

  Defined at drivers/rtc/Kconfig:8                                      

  Depends on: !S390 && !UML                                             

  Selects: RTC_LIB [=y]  

```

I also have RTC_SYSTOHC enabled. I didn't see any references in the kernel config to "enhanced" RTC (even after the 'z' toggle) but, as you say, these shouldn't be enabled anyway... 

I do *not* have RTC_HCTOSYS enabled however-- should I for some reason?

dq

----------

## NeddySeagoon

don quixada,

Neither of those settings matter if you have a dud CMOS battery.

One sets the system time form the CMOS clock on boot, the other updates the BIOS clock from time to time if you have NTP sync.

Neither is essential if ntp time sync works.

----------

## don quixada

Ok, but I'm not totally convinced that the CMOS battery is low. I leave my machine on most of the time but when I turn it off it doesn't necessarily affect the system clock. And also, sometimes the time becomes "unsynced" while the computer is running... 

An /etc/init.d/ntpd restart fixes the problem but that's not a good solution and doesn't resolve why ntpd crashes. 

Regardless, I can still test the battery to see if there's anything wrong with it...

dq

----------

## NeddySeagoon

don quixada,

The system real time clock is operated from the master clock oscillator once the system is running.  The master clock oscillator is controlled by a cheap crystal that is always slow.

Fast crystals can be slowed down to improve the accuracy but slow ones are always slow.  For controlling the CPU, it doesn't matter much.  For controlling the BIOS time it matters a lot, so better crystals are used here.

Once upon a time, before NTP, computer clocks were correct at power up and lost time with increasing uptime.   NTP fixed that mostly.

Modern CPUs have other timekeeping methods too.  Please post your dmesg.  I need it from the start to see what it says about the stability of the tsc.

Has the NTP problem always been present or is it new?

If its new, that indicates that something has changed.

----------

## don quixada

It's been a problem for quite awhile. Definitely over a year maybe two. I'm just getting fed up enough to deal with it now... :-P I'll post my dmesg when I get home tonight.

dq

----------

## don quixada

Ok, actually my dmesg is very unhelpful, it's not even worth posting. It's inundated by my Shorewall rejecting a connection within my local network. 

dq

----------

## ct85711

 *Quote:*   

> Ok, actually my dmesg is very unhelpful, it's not even worth posting. It's inundated by my Shorewall rejecting a connection within my local network. 

 

While you may think that is unhelpful, it DOES give quite a bit of information.  One thing it tells us, is that there is a good indication your shorewall configuration may not be correct.  2 things, going through your older logs, how long have you been getting flooded with connection rejected messages?  (Having a large log size can also indicate this).  While that message may not be related to this issue, it is still an issue you need to look at.

Second, have you tried disabling your firewall on the computer (so nothing is blocked) to see if it's not your firewall?

Note:  I am not saying to keep it disabled for extended periods of time, but disabling the firewall temporarily is a easy test to do, often helpful on troubleshooting a networking issue.

----------

## don quixada

I tried to disable shorewall but there is no change in the ntpd status.

Here's the dmesg if it helps:

http://pastebin.com/NmzsDya1

The ip address ending in 43 is my Chromecast. Don't know why it's trying to connect to this computer...

dq

----------

## don quixada

@ct85711 or @NeddySeagoon did you get a chance to look at my dmesg? 

dq

----------

## ct85711

the part I find strange, is that if ntpd is crashing, it should have posted some log messages indicating why

just a quick check around the web, common reasons for it to crash, is your time is too far out of sync, ntpd is unable to connect to any ntp server, and sometimes when the interface address changes (there were reports of issues with vmware/virtualization causing issues too).

generally, ntp uses UDP port 123 for it's communication.  Most times you shouldn't have to mess with that, if your firewall has the usual accept established,related traffic rule.

Now one thing you may want to do, is have your firewall stop logging the dropped traffic from your chromecast (so your logs are not being flooded).  That's assuming your chromecast is working properly.

I did notice you have some messages from destination port 515 and 9100, both related to printing (9100 is supposedly common for hp printers), so something to look at if you are having trouble printing.

For ntp server, if you need to, you can use the {0-3}.pool.ntp.org pool addresses (pool addresses for public ntp servers).

----------

## NeddySeagoon

don quixada,

There is noting useful in dmesg because of the logspam.

Be sure that your shorewall allows ntp requests out.

----------

## don quixada

I could try opening the port although ntpd does seem to run fine and fix the time when I first run it but then it subsequently crashes. So it can't be run as a service it seems. Anyway, I'll try opening the ports on both my shorewall and router...

It's weird that I'm getting printing related errors because I do not even have a printer installed anywhere on any machine. I suppose I do have CUPS installed but I'm not even printing to PS/PDF often on this machine either...

dq

----------

## don quixada

Ok, I disabled the logging to dmesg for shorewall. And I also opened the UDP port 123 but ntpd still reports a crashed status after being started...

dq

----------

## ct85711

now, the one thing we haven't considered, is if this crashed state is actually correct or not...

one test we can do, and may give us direct confirmation of what ntpd is actually doing it, run it our selves (in the foreground) and watch the messages.

Now, for me I am using the openntpd-5.9_p1 package (version shouldn't matter, but that I am using openntpd may affect the options, so you may want to double check them in the man page).

So what you should do, is first:  turn off ntpd  (/etc/init.d/ntpd stop works well enough).

second, as root run ntpd -d -v

for me, the man page states:

```
The options are as follows:

     -d          Do not daemonize.  If this option is specified, ntpd will run

                 in the foreground and log to stderr.

     -f file     Use file as the configuration file, instead of the default

                 /etc/ntpd.conf.

     -n          Configtest mode.  Only check the configuration file for

                 validity.

     -p file     Write pid to file

     -S          Do not set the time immediately at startup.  This is the

                 default.

     -s          Try to set the time immediately at startup, as opposed to

                 slowly adjusting the clock.  ntpd will stay in the foreground

                 for up to 15 seconds waiting for one of the configured NTP

                 servers to reply.

     -v          This option allows ntpd to send DEBUG priority messages to

                 syslog.

```

a sample, of what the output I had on my screen showed

```
Oate ct85711 # ntpd -dv

ntp engine ready

peer 96.44.154.34 now valid

peer 108.59.2.24 now valid

peer 4.53.160.75 now valid

peer 52.10.158.52 now valid

peer 2001:418:3ff::1:53 now valid

peer 107.170.224.8 now valid

peer 129.250.35.251 now valid

peer 74.117.214.3 now valid

peer 2600:3c00::f03c:91ff:fe89:8d0b now valid

peer 204.9.54.119 now valid

peer 54.236.224.171 now valid

peer 128.138.141.172 now valid

peer 24.56.178.140 now valid

peer 209.114.111.1 now valid

peer 64.6.144.6 now valid

peer 108.61.73.243 now valid

peer 2607:fa18::2407 now valid

peer 2600:3c00::e:d0bb now valid

peer 104.131.53.252 now valid

peer 66.228.42.59 now valid

peer 24.56.178.140 now invalid

clock is now synced

peer 24.56.178.140 now valid

^Cntp engine exiting

Terminating

```

Note:  I don't have anything special in my ntpd.conf file, only thing is servers [0-3].gentoo.pool.ntp.org  (so basically, a default configuration).

Leave the console window open, and watch to see if it does crash and what messages it gives (do give up a copy of the output when it crashes, doesn't need to be everything but like last 50 or so lines would start, I'm assuming earlier than the final message may give more information, hence the 50, though you can do more).

Edit:  I did not check my syslog messages to see if that posted any information when I ran using the -v option, so may want to check that too just in case.

----------

## don quixada

Here's what seems to be the equivalent of what you posted:

```
# ntpd -q

29 Apr 21:09:42 ntpd[29316]: ntpd 4.2.8p6@1.3265-o Tue Apr 26 16:00:17 UTC 2016 (1): Starting

29 Apr 21:09:42 ntpd[29316]: Command line: ntpd -q

29 Apr 21:09:42 ntpd[29316]: proto: precision = 0.119 usec (-23)

29 Apr 21:09:42 ntpd[29316]: Listen and drop on 0 v6wildcard [::]:123

29 Apr 21:09:42 ntpd[29316]: Listen and drop on 1 v4wildcard 0.0.0.0:123

29 Apr 21:09:42 ntpd[29316]: Listen normally on 2 lo 127.0.0.1:123

29 Apr 21:09:42 ntpd[29316]: Listen normally on 3 enp3s0 192.168.1.151:123

29 Apr 21:09:42 ntpd[29316]: Listen normally on 4 lo [::1]:123

29 Apr 21:09:42 ntpd[29316]: Listen normally on 5 enp3s0 [fe80::62a4:4cff:fe64:1a90%2]:123

29 Apr 21:09:42 ntpd[29316]: Listening on routing socket on fd #22 for interface updates

29 Apr 21:09:43 ntpd[29316]: ntpd: time slew -0.007117 s

ntpd: time slew -0.007117s
```

I tried to raise the debug level but it doesn't seem to affect anything. Not sure what the above means and it doesn't seem to show an error... It exited by itself.

dq

----------

## szatox

Try this and see what happens:

busybox ntpd -w

if it fails, keep looking for problems in your network configuration. If it works, it will most likely be an issue with the ntpd binary itself, linking, or (less likely, as it's really hard to screw up) config files.

Note: it may fail with a message like "ntpd: bad address <xxx>". Resolve it manually and launch the below instead:

busybox ntpd -w -p <ip of ntp server>

Also, if you have customized the configs, test it with gentoo's default servers too: [0-3].gentoo.pool.ntp.org

----------

## don quixada

Ok, so I get the following output:

```

# busybox ntpd -w -p 0.gentoo.pool.ntp.org

ntpd: bad address '0.gentoo.pool.ntp.org'
```

But if I used the ip-address for that domain I get:

```

# busybox ntpd -w -p 199.204.45.235

ntpd: reply from 199.204.45.235: offset:+0.002984 delay:0.042645 status:0x24 strat:2 refid:0x96cb9618 rootdelay:0.018219 reach:0x01

ntpd: reply from 199.204.45.235: offset:+0.003082 delay:0.038158 status:0x24 strat:2 refid:0x96cb9618 rootdelay:0.018219 reach:0x03

```

I am using OpenDNS for my dns servers and maybe it's blocking the domain name but if I can ping the domain name then it isn't blocked right? Anyway I added the 0.gentoo.pool.ntp.org domain to my whitelist and disabled all domain blocking and the problem is still happening. 

Also, I added 199.204.45.235 to my ntp.conf in the servers list but there was no change.

The weird thing is that it was actually working for a bit without changing any of my settings but now, after a reboot, it crashes immediately again.

dq

----------

## szatox

I suppose busybox fails to notice that address is a domain name rather than IP because it starts with a digit.  :Rolling Eyes: 

Anyway, the second output shows it's working. So it's definitely related to the ntp binaries you're using and _NOT_ a network issue. And as a side note, your clock's drift is minimal, so it doesn't make a reason for ntpd to give up.

In fact the drift is so small it makes me think your ntpd is running. Have you grepped through running processes?

if it really does crashes.. well, maybe you will find something useful here:

1) stick with busybox (it supports both, client and daemon mode), just modify/replace init scripts

2) fix the implementation you have.  Perhaps rebuilding this stuff:

```
# bjdump -p $(which ntpd) | grep NEEDED

  NEEDED               libm.so.6

  NEEDED               libcrypto.so.1.0.0

  NEEDED               libdns_sd.so.1

  NEEDED               libpthread.so.0

  NEEDED               libc.so.6

```

3) try debugging it first. I can't help much with this though.

----------

