[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
>>> 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
> 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.
> 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