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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
