[ntp:questions] Finding out where ntpd gets its ntp.conf file

Joseph Gwinn joegwinn at comcast.net
Thu Sep 4 10:46:21 UTC 2008


In article <yvudnf7rXeMsOyPVnZ2dnUVZ_gSdnZ2d at comcast.com>,
 "Richard B. Gilbert" <rgilbert88 at comcast.net> wrote:

> Joseph Gwinn wrote:
> > We had been struggling with NTP running on Red Hat Enterprise Linux 
> > (RHEL) on IBM-built Intel boxes, specifically with getting NTP to 
> > generate loopstats and peerstats files.  Basically, nothing worked, 
> > despite many attempts.  
> > 
> > Yesterday, I cracked it while working on the problem with one of the 
> > sysadmins.  The ntp.config file was very complex, and I suspected it of 
> > being mostly flotsam and jetsam from prior uses, and probably in 
> > conflict with itself, so we cleaned it down to maybe three lines, and 
> > then stopped and started ntpd using the "service" utility.
> > 
> > The daemon started, but complained that it was unable to synchronize.  
> > The sysadmin mentioned that it very often did this, for unknown reasons.  
> > Then I noticed that the timeserver IP address was not the same as 
> > specified in the simplified ntp.conf file, and sure enough the address 
> > that NTP was trying to use was not accessible to ping.
> > 
> > Hmm.  Huh?  NTP cannot be using the ntp.conf file we thought it was.  
> > Tried starting NTP manually with -c option and providing the full path 
> > to our ntp.conf file.  Success!
> > 
> > Read the "service" shell script.  It appears to get its file paths from 
> > environment variables named after the thing being started and stopped 
> > and accessible only in the root environment; this bit of RHEL-specific 
> > structure is being chased down.  (Does anyone know where this is 
> > documented?)
> > 
> > Which brings me to a question:  How does one get NTP to tell you exactly 
> > where it is getting such things as the ntp.conf file from, all without 
> > being able to find or see the actual command line or lines that launched 
> > the daemon?  I did not see a ntpq command that sounded plausible, 
> > although ntpq would be an obvious choice.
> > 
> > This would be very useful for debugging, as each and every platform type 
> > seems to have a different approach to handling NTP.  
> > 
> > Joe Gwinn
> 
> I don't recall ever encountering such a facility.  Or ever needing one.

You are very fortunate.  I do need one.  

You have confirmed my suspicion that NTP has no such facility.

Use of strace has been suggested.  It is on some but not all platforms 
at present.


> It seems to me that this is the sort of thing that the sysadmin should 
> be documenting.  And if he has not documented it, perhaps you should 
> wonder what's going to happen when he walks in front of a truck, or is 
> shot by an irate husband!

In this case, none of the sysadmins (who are too busy) had any idea what 
was going on, and they didn't know enough about NTP to realize what was 
going on.  The sysadmin had gotten the can't-sync error message many 
times, but didn't quite understand what it was saying.  So even if he is 
hit by an irate truck, his replacement won't necessarily be better or 
worse.

The problem I'm trying to solve is different.  We put NTP on lots of 
different kinds of computer, mostly Unix, but some Windows, and I'm 
looking for diagnosis tools that will tell me what's really going on, 
precisely so I can debug unfamiliar setups no matter how screwed up.

Thanks,

Joe Gwinn




More information about the questions mailing list