Finding out where ntpd gets its ntp.conf file - NTP

This is a discussion on Finding out where ntpd gets its ntp.conf file - NTP ; Joseph Gwinn wrote: > In article , > "Richard B. Gilbert" wrote: > >> Joseph Gwinn wrote: >>> In article , >>> Martin Burnicki wrote: >>> >>>> Joe, >>>> >>>> Joseph Gwinn wrote: >>>>> In article , >>>>> "Peter J. ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 72

Thread: Finding out where ntpd gets its ntp.conf file

  1. Re: Finding out where ntpd gets its ntp.conf file

    Joseph Gwinn wrote:
    > In article ,
    > "Richard B. Gilbert" wrote:
    >
    >> Joseph Gwinn wrote:
    >>> In article <30s4p5-as9.ln1@gateway.py.meinberg.de>,
    >>> Martin Burnicki wrote:
    >>>
    >>>> Joe,
    >>>>
    >>>> Joseph Gwinn wrote:
    >>>>> In article <48bf5d9c$0$21355$c30e37c6@pit-reader.telstra.net>,
    >>>>> "Peter J. Cherny" wrote:
    >>>>>
    >>>>>> Joseph Gwinn wrote:
    >>>>>>> ...
    >>>>>>> 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
    >>>>>> >...
    >>>>>> [peterc@tantalus ~]$ strings /usr/sbin/ntpd|grep ntp.conf
    >>>>>> /etc/ntp.conf
    >>>>> In the RHEL case, this would find exactly the wrong copy of ntp.conf,
    >>>>> being the one we were changing to no avail, not the one that NTP was in
    >>>>> fact using.
    >>>>>
    >>>>>
    >>>>>> [peterc@tantalus ~]$ strace -f -o x /usr/sbin/ntpd -g
    >>>>> I'll have to look into this. It sounds like it might be general enough.
    >>>>>
    >>>>>
    >>>>>> [root@tantalus ~]# grep ntp.conf x
    >>>>>> 3351 open("/etc/ntp.conf", O_RDONLY) = 4
    >>>>> Doesn't this assume that the correct "ntp.conf" file is called ntp.conf?
    >>>>> It may be common, the standard convention, but it is not required.
    >>>>>
    >>>>> The whole point is to find the correct file without making assumptions,
    >>>>> because on a strange computer strange things may have been done.
    >>>> I fully agree.
    >>>>
    >>>> Ntpd generates a bunch of messages about what it has found in the config
    >>>> file, at least in debug mode.
    >>>>
    >>>> Maybe you should open an enhancement request on http://bugs.ntp.org to make
    >>>> ntpd also print the name of the config file it is using, maybe only in
    >>>> debug mode.
    >>> I'm surprised that it doesn't already print the full filename of every
    >>> file it uses.
    >>>
    >>> Will debug mode do much if the binary wasn't compiled for debug? I'm
    >>> trying to use the provided binary, whatever it might be, and recompiling
    >>> is usually far too much trouble to be practical. Especially as the
    >>> effort is per platform type, and we have multiple types.
    >>>
    >>> I will file an enhancement request. However, my feeling is that this
    >>> function would be most useful if added to ntpq, and yielded the full
    >>> filename including directories, as there may be multiple "ntp.conf"
    >>> files scattered about. The key is to get NTP to tell us which file NTP
    >>> is using, without interference from our firmly held but sadly mistaken
    >>> assumptions about what NTP ought to be doing.
    >>>
    >>> Joe Gwinn

    >> Since the source to NTPD is available, it's a SMOP to modify it to print
    >> out the desired file specification!

    >
    > True enough, but far too much work.
    >


    True enough but then why would you expect someone else to do it for you?


  2. Re: Finding out where ntpd gets its ntp.conf file

    In article ,
    "Richard B. Gilbert" wrote:

    > Joseph Gwinn wrote:
    > > In article ,
    > > Steve Kostecke wrote:
    > >
    > >> On 2008-09-03, Joseph Gwinn wrote:
    > >>
    > >>> 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?)
    > >> On Linux OSes init scripts are typically found in /etc/init.d/ or
    > >> /etc/rc.d/init.d/ Look for one named ntp (or something containing ntp).

    > >
    > > Yes, and that's where strace led me, where I found a script called ntpd.
    > > How the service script interacts with this ntpd script isn't clear.
    > > Environment variables seem to be implicated, but a listing of
    > > environment variables is not helpful. Next week I'll digest it all.
    > >
    > >
    > >>> 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.
    > >> Why not use the file location features built in to your OS to find all
    > >> possible instances of ntp.conf?
    > >>
    > >> $ locate ntp.conf
    > >>
    > >> or
    > >>
    > >> $ find / -name ntp.conf
    > >>
    > >> Pipe the output of either of those commands to 'xargs ls -l' to see the
    > >> datestamps of the files.

    > >
    > > We did this, but could not tell which one mattered. Next week.
    > >
    > > Nor is it *required* the the ntp configuration file be called ntp.config.
    > >
    > >
    > > Joe Gwinn

    >
    > There MIGHT, in rare cases, be good reason NOT to call the configuration
    > file "ntp.conf" (it's conf not config, unless someone changed it
    > recently). IF so, both the new name and the reasons for it should be
    > documented! In most cases it's best to stick with the de facto standard.


    I agree completely. But I didn't set the thing up. But I do have to
    figure it out and fix it. And document it. It did flummox all our
    sysadmins, although as with sysadmins worldwide they are too busy.

    Joe Gwinn

  3. Re: Finding out where ntpd gets its ntp.conf file

    Joseph Gwinn writes:

    >In article ,
    > Steve Kostecke wrote:


    >> On 2008-09-03, Joseph Gwinn wrote:
    >>
    >> > 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?)

    >>
    >> On Linux OSes init scripts are typically found in /etc/init.d/ or
    >> /etc/rc.d/init.d/ Look for one named ntp (or something containing ntp).


    >Yes, and that's where strace led me, where I found a script called ntpd.
    >How the service script interacts with this ntpd script isn't clear.
    >Environment variables seem to be implicated, but a listing of
    >environment variables is not helpful. Next week I'll digest it all.


    service simply runs the program listed as its argument from the /etc/init.d
    directory.

    Ie, service ntpd start is the same as
    /etc/init.d/ntpd start


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

    >>
    >> Why not use the file location features built in to your OS to find all
    >> possible instances of ntp.conf?
    >>
    >> $ locate ntp.conf
    >>
    >> or
    >>
    >> $ find / -name ntp.conf
    >>
    >> Pipe the output of either of those commands to 'xargs ls -l' to see the
    >> datestamps of the files.


    >We did this, but could not tell which one mattered. Next week.


    >Nor is it *required* the the ntp configuration file be called ntp.config.



    >Joe Gwinn


  4. Re: Finding out where ntpd gets its ntp.conf file

    Martin Burnicki wrote:
    > Steve Kostecke wrote:
    >
    >> On 2008-09-04, Peter J. Cherny wrote:
    >>
    >>> In most OSs the man pages are definitive and mostly correct,

    >> Any NTP documentation distributed as man pages is produced by third
    >> parties and should not be viewed as authoritative.

    >
    > Hm, the current repos (both -dev and -stable) contain a .1 file for every
    > binary which seems to be some kind of template to generate at least a man
    > page ...


    They are the man pages. They are at the same abstraction level as HTML
    files and, on most systems, are rendered to the final form on demand.

    However, they are stub pages (i.e. they are far from complete), and they
    are not parameterised by the build system, so are not helpful here. In
    addition, their presence appears to be in direct contravention of the
    official policy on documentation in the official distributions.

    They are also installed in the wrong place. Manual section 1 is for
    unprivileged user documents, but the NTP tools, and, in paticular, ntpd
    are system manager documents and should be in section 8 and have .8
    suffixes.

  5. Re: Finding out where ntpd gets its ntp.conf file

    In article <8Mhwk.629$yS5.294@edtnps83>,
    Unruh wrote:

    > Joseph Gwinn writes:
    >
    > >In article ,
    > > Steve Kostecke wrote:

    >
    > >> On 2008-09-03, Joseph Gwinn wrote:
    > >>
    > >> > 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?)
    > >>
    > >> On Linux OSes init scripts are typically found in /etc/init.d/ or
    > >> /etc/rc.d/init.d/ Look for one named ntp (or something containing ntp).

    >
    > >Yes, and that's where strace led me, where I found a script called ntpd.
    > >How the service script interacts with this ntpd script isn't clear.
    > >Environment variables seem to be implicated, but a listing of
    > >environment variables is not helpful. Next week I'll digest it all.

    >
    > service simply runs the program listed as its argument from the /etc/init.d
    > directory.
    >
    > Ie, service ntpd start is the same as
    > /etc/init.d/ntpd start


    True, but there seems to be more to it than that. Next week.

    Joe Gwinn

  6. Re: Finding out where ntpd gets its ntp.conf file

    David Woolley wrote:
    > Martin Burnicki wrote:
    >> Steve Kostecke wrote:
    >>
    >>> On 2008-09-04, Peter J. Cherny wrote:
    >>>
    >>>> In most OSs the man pages are definitive and mostly correct,
    >>> Any NTP documentation distributed as man pages is produced by third
    >>> parties and should not be viewed as authoritative.

    >>
    >> Hm, the current repos (both -dev and -stable) contain a .1 file for every
    >> binary which seems to be some kind of template to generate at least a man
    >> page ...

    >
    > They are the man pages. They are at the same abstraction level as HTML
    > files and, on most systems, are rendered to the final form on demand.


    Hm, I must confess I have never thought about the way man pages are
    generated.

    > However, they are stub pages (i.e. they are far from complete), ...


    I *think* they are just generated by the libopts program which is now used
    for command line option processing for NTP, so it basically contains only
    those pieces of information which are also printed by the programs' usage
    messages.

    > ... and they
    > are not parameterised by the build system, so are not helpful here. In
    > addition, their presence appears to be in direct contravention of the
    > official policy on documentation in the official distributions.
    >
    > They are also installed in the wrong place. Manual section 1 is for
    > unprivileged user documents, but the NTP tools, and, in paticular, ntpd
    > are system manager documents and should be in section 8 and have .8
    > suffixes.


    Harlan, should we open a big on this?

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  7. Re: Finding out where ntpd gets its ntp.conf file

    Joseph Gwinn wrote:
    > In article <4357p5-evq.ln1@gateway.py.meinberg.de>,
    > Martin Burnicki wrote:

    [...]
    >> If ntpd would write a log message at startup then you could easily find
    >> out on every platform which config file has been read.

    >
    > That would certainly work, and work in all cases.


    However, this would only be useful in future versions of the package.

    > My problem is to debug NTP problems in multiple systems that I have
    > limited knowledge of, ones that may or may not follow the usual
    > conventions, or the same conventions, and which may in fact may have
    > been hosed up by some sysadmin who knows nothing of NTP save where the
    > big red start button is supposed to be.


    In the current case using strace to find which files are actually opened and
    read when ntpd starts (as proposed elsewhere) should be the best solution.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  8. Re: Finding out where ntpd gets its ntp.conf file

    Martin Burnicki wrote:

    > In the current case using strace to find which files are actually opened and
    > read when ntpd starts (as proposed elsewhere) should be the best solution.
    >
    > Martin


    use strace -e trace=file ..
    to see all syscalls that use a filename string.


    uwe

  9. Re: Finding out where ntpd gets its ntp.conf file

    Martin,

    Rahul's GSoC project had to do with autogen and the generated man pages.

    Stock autogen produced .1 and .3 pages.

    We will soon be able to produce .8 pages as well.

    And while right now the man pages are mostly useful for command-line
    invocation, the intent is that we will use the .def files for each program
    to producea "full" page, in man, html, and perhaps some other formats.

    At this point I'm not sure a bugzilla item will matter, it is a fairly large
    job, and I am tracking it at http://support.ntp.org/Dev/GNUAutoGenConversion

    I'm happy to have more feedback on these issues.
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

  10. Re: Finding out where ntpd gets its ntp.conf file

    Harlan,

    thanks for the update.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  11. Re: Finding out where ntpd gets its ntp.conf file

    Uwe Klein wrote:

    > Martin Burnicki wrote:
    >
    >> In the current case using strace to find which files are actually opened
    >> and read when ntpd starts (as proposed elsewhere) should be the best
    >> solution.
    >>
    >> Martin

    >
    > use strace -e trace=file ..
    > to see all syscalls that use a filename string.


    Unless -f is also given to strace this may not catch the correct file when
    the daemon forks.

    Since we want to track which files are opened by ntpd a variant of Peter J.
    Cherny's proposal works nice:

    strace -f -e trace=open -o x ntpd

    or, to include the effects of the startup script:

    strace -f -e trace=open -o x /etc/init.d/ntpd start

    In both cases all open() calls can be found in the text file x. In the
    latter case it may be necessary to kill ntpd afterwards from a different
    console since strace does not terminate while ntpd still runs as daemon.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  12. Re: Finding out where ntpd gets its ntp.conf file

    Martin Burnicki wrote:
    > Uwe Klein wrote:
    >
    >
    >>Martin Burnicki wrote:
    >>
    >>
    >>>In the current case using strace to find which files are actually opened
    >>>and read when ntpd starts (as proposed elsewhere) should be the best
    >>>solution.
    >>>
    >>>Martin

    >>
    >>use strace -e trace=file ..
    >>to see all syscalls that use a filename string.

    >
    >
    > Unless -f is also given to strace this may not catch the correct file when
    > the daemon forks.
    >
    > Since we want to track which files are opened by ntpd a variant of Peter J.
    > Cherny's proposal works nice:
    >
    > strace -f -e trace=open -o x ntpd
    >
    > or, to include the effects of the startup script:
    >
    > strace -f -e trace=open -o x /etc/init.d/ntpd start


    yes you need "-f" too, see my other post.

    But use trace=file ( and equivalent to trace=open,stat,chmod,unlink,... )

    "file" is a basket for all fileops with a string arg ( stat(), open() unlink() ...
    That way you not only see the files opened but often more interesting the
    places that are searched for certain files.

    uwe

  13. Re: Finding out where ntpd gets its ntp.conffile

    >>>>> "Joseph" == Joseph Gwinn writes:

    Joseph> so we cleaned [ntp.conf] down to maybe three lines, and
    Joseph> then stopped and started ntpd using the "service" utility.

    Joseph> Read the "service" shell script. It appears to get its file
    Joseph> paths from environment variables named after the thing being
    Joseph> started and stopped and accessible only in the root environment

    I read through most of the replies so far, but one thing I haven't seen
    noted is that this isn't an ntp issue at all, but rather that you were
    using system(8) as a black box.

    Anyone starting or stopping daemons needs to know how the distribution
    in use does it and should emulate that as close as possible.

    I haven't used RH is years, and am not familiar with system(8) or how
    well it is documented (and am writing this while offline and so cannot
    look it up), but it is almost always the case that things will break if
    services are started in anything other than a root login or su - session.
    Even when using sudo(8) it is best to 'su -' before starting daemons.

    Anyone administrating any box simply needs to know how the specific
    distribtuion does things in order to safely customize the install.

    -JimC
    --
    James Cloos OpenPGP: 1024D/ED7DAEA6

  14. Re: Finding out where ntpd gets its ntp.conf file


    >Yes, ntp debug is different from gcc debug.
    >However, if you are assuming that the distro people can screw things up
    >then they can screw up any changes that is made to the original source.
    >They can simply go in and disable the reporting even if it is put in.


    The biggest screwup the distro people are likely to do is to
    continue to use an old version long after everybody here has
    forgotten about its quirks.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  15. Re: Finding out where ntpd gets its ntp.conf file


    >> [peterc@tantalus ~]$ strings /usr/sbin/ntpd|grep ntp.conf
    >> /etc/ntp.conf


    >In the RHEL case, this would find exactly the wrong copy of ntp.conf,
    >being the one we were changing to no avail, not the one that NTP was in
    >fact using.


    It's even worse than that. You aren't even sure that's
    the right copy of ntpd to be searching.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  16. Re: Finding out where ntpd gets its ntp.conf file

    James Cloos wrote:

    > I read through most of the replies so far, but one thing I haven't seen
    > noted is that this isn't an ntp issue at al


    Did you mean service (8).

    Treating it as a black box is basically how Red Hat is marketed; it is
    basically in the same market as Windows. People who want a white box
    Linux are more likely to choose something like Slackware.

    I think the OP has gone far beyond what the average RHEL administrator
    is expected to do in terms of looking inside the box.

  17. Re: Finding out where ntpd gets its ntp.conf file


    >Yes, and that's where strace led me, where I found a script called ntpd.
    >How the service script interacts with this ntpd script isn't clear.
    >Environment variables seem to be implicated, but a listing of
    >environment variables is not helpful. Next week I'll digest it all.


    I think there are two parts to this discussion. One is how to debug
    this particular problem. The other is how to make ntpd easier to
    debug.


    [I'm using a really really old RH and Fedora 7.]

    service ntpd start just runs /etc/init.d/ntpd start

    /etc/init.d/ntpd is just a script. You can debug it
    just like you debug any other script.

    mine says
    if [ -f /etc/sysconfig/ntpd ];then
    . /etc/sysconfig/ntpd
    fi
    and
    ntpconf=/etc/ntp.conf

    I think the last line is misleading. I think it's leftover
    from when it used to be normal to use ntpdate and it was
    getting the servers for ntpdate out of the ntpd config file.

    I seem to remember hacking my startup stuff to include
    a few printfs/echos when I was debugging something.

    A quick check in your /etc/sysconfig/ntpd might be interesting.



    There are two things that might add to the confusion in this area.

    RH (and many other distributions) used to have their own copy
    of the sources that was patched so they could run ntpd as non-root.
    That makes it easier to add other patches. Who knows what they
    really did.

    Some systems use a chroot jail. I don't know much about them,
    but I wouldn't be surprised if that used the wrong ntp.conf.


    I agree that it might have made your debugging easier if
    ntpd had logged the exact answer to your question. On
    the other hand, most of the time that would just be clutter.

    ntpd has a switch on the command line that generates
    a lot of debugging printout. I haven't used it in a while.
    I think you have to run ntpd from a terminal without going
    into deamon mode.

    It might be helpful to have a command line switch that would
    log all the "interesting" stuff that was needed for debugging
    configuration problems.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  18. Re: Finding out where ntpd gets its ntp.conf file

    [man pages]

    >I'm happy to have more feedback on these issues.


    My 2 cents...

    I like man pages. apropos is where I start when I'm looking
    for things.

    I hate buggy documentation. That includes out of date man pages.

    I'd be happy with dummy man pages that told me to look in
    the HTML pages and where to find them.

    Are most distributions setup to deal with HTML documentation?
    Is there a common default place to put it?

    If not, the collection on the web somewhere at ntp.org is
    probably good enough.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  19. Re: Finding out where ntpd gets its ntp.conf file

    Hal Murray wrote:
    >>>[peterc@tantalus ~]$ strings /usr/sbin/ntpd|grep ntp.conf
    >>>/etc/ntp.conf

    >
    >
    >>In the RHEL case, this would find exactly the wrong copy of ntp.conf,
    >>being the one we were changing to no avail, not the one that NTP was in
    >>fact using.

    >
    >
    > It's even worse than that. You aren't even sure that's
    > the right copy of ntpd to be searching.
    >

    going back from who is using the relevant port is allways usefull ;-)

    ( cd /proc ; ls -l $(fuser -v -n udp ntp 2>/dev/null )/exe )
    --> lrwxrwxrwx 1 root root 0 Sep 9 04:10 25843/exe -> /usr/sbin/ntpd

    uwe

  20. Re: Finding out where ntpd gets its ntp.conffile

    Jim,

    At 6:30 PM -0400 9/8/08, James Cloos wrote:
    > >>>>> "Joseph" == Joseph Gwinn writes:

    >
    >Joseph> so we cleaned [ntp.conf] down to maybe three lines, and
    >Joseph> then stopped and started ntpd using the "service" utility.
    >
    >Joseph> Read the "service" shell script. It appears to get its file
    >Joseph> paths from environment variables named after the thing being
    >Joseph> started and stopped and accessible only in the root environment
    >
    >I read through most of the replies so far, but one thing I haven't seen
    >noted is that this isn't an ntp issue at all, but rather that you were
    >using system(8) as a black box.


    It is certainly true that our sysadmins knew little of how service
    works. Their main effort to date has been with the AIX servers.

    I'm not a sysadmin, but am digging into service. I don't recall that
    the service man page was that helpful, but will look again.


    >Anyone starting or stopping daemons needs to know how the distribution
    >in use does it and should emulate that as close as possible.


    True enough, but harried sysadmins don't necessarily achieve this.

    Nor do our sysadmins know that much about time, and were using NTP as
    a black box.

    When they have a time-related problem, I get the call. So far, I've
    been able to figure the root causes out. They were not able to
    figure out why we could not get loopstats and peerstats recording to
    work - it was the trojan ntp.conf file.


    >I haven't used RH is years, and am not familiar with system(8) or how
    >well it is documented (and am writing this while offline and so cannot
    >look it up), but it is almost always the case that things will break if
    >services are started in anything other than a root login or su - session.
    >Even when using sudo(8) it is best to 'su -' before starting daemons.


    At least for ntpd, one must be in root (or use su) for service to
    work under RHEL, because every thin the sysadmin forgot to su,
    service ntpd start/stop failed.


    >Anyone administrating any box simply needs to know how the specific
    >distribution does things in order to safely customize the install.


    Absolutely. We are now figuring this out. I have no idea who
    generated the cruft-laden ntp.conf files.

    Joe


    >-JimC
    >--
    >James Cloos OpenPGP: 1024D/ED7DAEA6


+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast