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

Richard B. Gilbert rgilbert88 at comcast.net
Thu Sep 4 14:12:12 UTC 2008


Joseph Gwinn wrote:
> 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

My memory grows DIMM but ISTR there is a program in at least some Unix 
or Unix-like operating systems that will tell you which program(s) have 
which files open.

Give me a few weeks or months to think about it and the answer will 
bubble up from the sludge at the bottom of my mind!




More information about the questions mailing list