"Richard B. Gilbert" <[EMAIL PROTECTED]> writes: >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. The config file is not kept open. It is read and then closed. The info does not change. >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
