login
Search
Slow Goat Riot is playing at 9 tonight at JA Michaels.
With that out of the way, can someone tell me why my NTP daemon keeps dying? Right now, I've got my router/web server (Trogdor) running an NTP daemon that gets updates from clock.xmission.com. To save hits on a stratum 1 server, my internal machines then update from Trogdor. The problem is, it runs for a day or so (at least some time over an hour), and then it just dies. I'm not really sure why. This of course causes the ntp daemons on my other machines to eventually kill themselves after enough time of no updates.
What I'm not good at with Linux is accident forensics. My suspicion is that Trogdor's ntpd is dying after not being able to get updates (probably during the time that my crappy cable provider goes on their monthly (sometimes weekly) nighttime outage. What I'd like to know is how can I confirm this. I don't believe that there's enough log information to know right now; is there a way to set that up?
Not forensics but..
I use government servers for my time.
server 131.107.1.10 prefer # time-nw.nist.gov
server 192.43.244.18 # time.nist.gov
server 129.6.15.28 # time-a.nist.gov
You could at least see if it's your prefer server, if you do use multiple servers.
I don't think my daemon has ever died, do you have local clock string still in there just in case such a power/connectivity issue arrises?
Fuck it, here's my entire ntpd.conf.
#
# ** CLIENT NTP SETTINGS **
#
# These two lines are a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 10. Since the server line dows not have the prefer keyword, this driver
# is never used for synchronization, unless no other source is available.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
# If you are configuring a client, use "server" entries to
# synchronize to NTP servers. For example:
# server ntp1.arizona.edu
#
server 131.107.1.10 prefer # time-nw.nist.gov
server 192.43.244.18 # time.nist.gov
server 129.6.15.28 # time-a.nist.gov
# The driftfile statement tells ntpd the name of the file
# in which to store the frequency error of the system clock.
# You are strongly encouraged to include this statement in
# the configuration file.
#
driftfile /etc/ntp/drift
-Les
Cover
Do you happen to know the cover at JA?
Lesta
too large a time differenece?
What could be happening is that the NTP server decides that the change it wants to make to the time on your machine is too large (above a threshold set in your config file). I've had my NTP daemons die on me for that reason.
true
That is true, but I wonder why it would be getting that far off. I make sure to ensure that the clock is synced with ntpdate before I let ntpd fly. Can a few hours of no updates (during a cablemodem outage) cause it to get that far off?