Joseph Gwinn wrote: > In article <[EMAIL PROTECTED]>, > "Richard B. Gilbert" <[EMAIL PROTECTED]> 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! _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
