ntp stopped working - here's the workaround

Hi

I am running Linux GoFlexNet 3.3.2-kirkwood-dg #1 Mon Apr 23 17:09:27 CDT 2012 armv5tel and noticed that newly copied files to my harddisks connected to my GoFlexNet (smb shares) had shown no date and time anymore in Windows-Explorer.
They were set to 1970-01-01 ...

The GoFlexNet has no HWCLOCK so it had to be ntpd that failed.
Somwhere else on the net I found the advice to remove the ntp-package with 'apt-get purge ntp' and re-install it afterwards.
That guy had the same symptoms I was having.

GoFlexNet:~# ntpq
ntpq>as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 19693  941a   yes   yes  none candidate    sys_peer  1
  2 19694  961a   yes   yes  none  sys.peer    sys_peer  1

querying ntpq with 'as' - whatever that means - showed only: (reach: no) (condition reject) or something similar. (sorry, now that it's working again - I can't post the former results) So it became clear to me that ntpd could not reach any NTP-servers.

after reinstalling ntp I changed only the following lines in /etc/ntp.conf :

server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

to

#server 0.debian.pool.ntp.org iburst
#server 1.debian.pool.ntp.org iburst
#server 2.debian.pool.ntp.org iburst
#server 3.debian.pool.ntp.org iburst
server fritz.box
server ptbtime1.ptb.de
server ptbtime2.ptb.de

now it works fine again :)

I did not add the lines

restricted ... fritz.box

(one line per server) at the end of ntp.conf as described in this post

phil

I've noticed that on my Pogoplugs (also no RTC) it used to take some time for them to sync up to the correct date and time after a reboot. I run with both ntpd and a local named DNS server installed and the problem seemed to be that ntp and DNS would come up before the networking and then sleep (actually, DNS goes into "svrfail") for a while before retrying. In addition, there is a catch-22: DNS needs some semblance of a correct date/time before it considers itself sane and usable, and NTP requires DNS to access its servers. I resolved the problem locally by doing the following:

1. I added an external nameserver to /etc/resolv.conf so that ntp isn't at the total mercy of the local nameserver.

2. I added the '-g' option (NTPD_OPTS='-g') to /etc/default/ntp. This allows ntpd to jump-set the date when it first comes up.

3. I modifed the /etc/network/if-up.d file to restart the ntp daemon as soon as networking comes up by doing the following:

I commented out the line
"/usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :"
and replaced it with the line
"invoke-rc.d --quiet ntp restart || true"

This allows ntpd to set the correct date as soon as it can instead of waiting for it to time out to retry.

I'm no expert on Debian startup, so I can't vouch that all this doesn't introduce other problems, but empirically it seems to work for me.

(Hey Punxsutawney, I hear there's a local prosecutor in Ohio that's put a price on your head!)



Edited 1 time(s). Last edit at 03/22/2013 09:51PM by restamp.

restamp Wrote:
-------------------------------------------------------

> 1. I added an external nameserver to
> /etc/resolv.conf so that ntp isn't at the total
> mercy of the local nameserver.

I have name server 8.8.8.8 in this file. Google seems to be very reliable.

> (Hey Punxsutawney, I hear there's a local
> prosecutor in Ohio that's put a price on your
> head!)

Crazy but true :))

Learnt from Jeff's script:

1. He used ntpdate instead of ntp, as ntpd is much bigger.

2. In the script for Squeeze:

echo HWCLOCKACCESS=no >> $ROOT/etc/default/rcS

3. In the script for Wheezy:

sed -i 's/^#*\(HWCLOCKACCESS\)=.*$/\1=no/' $ROOT/etc/default/hwclock

All the above was lost after my upgrade.

Add:

FYI, I did

sed -i 's"^\(.*dnssec-validation auto;\)$"//\1"' /etc/bind/named.conf.options

to suppress the warning from named when it started.

-syong



Edited 3 time(s). Last edit at 03/23/2013 09:17AM by syong.

bodhi Wrote:
-------------------------------------------------------
> I have name server 8.8.8.8 in this file. Google
> seems to be very reliable.

The one problem I've had with Google nameservers, aside from their penchant for collecting personal information on us, is that for some reason they completely break the dnsbl feature of sendmail. Dnsbl works by using especially crafted reverse lookup domain names to denote whether a site has been adjudicated as a spam site, and when my email servers were converted to using Google nameservers those inquiries were ineffective and my spam content went up appreciably.

YMMV