Re: clock keeps getting behind, driftfile is 0.000 - NTP

This is a discussion on Re: clock keeps getting behind, driftfile is 0.000 - NTP ; > chantal@antenna.nl writes: > chantal> Hi list, the time on one of our servers is incorrect despite using > chantal> ntpd, I also noticed that the driftfile value is 0.000 and doesn't > chantal> changed. What could be the problem? ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: clock keeps getting behind, driftfile is 0.000

  1. Re: clock keeps getting behind, driftfile is 0.000


    > chantal@antenna.nl writes:
    > chantal> Hi list, the time on one of our servers is incorrect despite using
    > chantal> ntpd, I also noticed that the driftfile value is 0.000 and doesn't
    > chantal> changed. What could be the problem?
    > chantal> Here is our conf file:
    >
    > Please read http://support.ntp.org/Support/AccessRestrictions .
    >
    > You can use 'ntpq -p' to see if you are syncing to any machines.


    Hi this, is the ntpq -p output:

    [root@server ~]# ntpq -p
    remote refid st t when poll reach delay offset jitter
    ================================================== ============================
    sectionzero.org 35.65.96.0 3 u 171 1024 376 2.065 347330. 4621.34
    steghoefer.eu 87.239.10.190 3 u 200 1024 377 2.182 351371. 4446.79
    nieuwland-240.c 213.136.12.53 3 u 132 1024 377 0.728 347218. 4448.43
    fw-enschede-6.i 193.190.230.65 2 u 201 1024 377 5.566 346919. 4457.15
    *LOCAL(0) .LOCL. 10 l 33 64 377 0.000 0.000 0.001

    The access restrictions in our conf file are only for prohibiting
    other servers to sync with this one, so it looks ok to me?

  2. Re: clock keeps getting behind, driftfile is 0.000

    wrote in message
    news:20080528080340.w75rcqu6ckc0gg84@webmail.mail5 .antenna.nl...

    > Hi this, is the ntpq -p output:
    >
    > [root@server ~]# ntpq -p
    > remote refid st t when poll reach delay offset
    > ================================================== =====================
    > sectionzero.org 35.65.96.0 3 u 171 1024 376 2.065 347330.
    > steghoefer.eu 87.239.10.190 3 u 200 1024 377 2.182 351371.
    > nieuwland-240.c 213.136.12.53 3 u 132 1024 377 0.728 347218.
    > fw-enschede-6.i 193.190.230.65 2 u 201 1024 377 5.566 346919.
    > *LOCAL(0) .LOCL. 10 l 33 64 377 0.000 0.000


    (Jitter column removed to fit on an 80-character line.)


    > The access restrictions in our conf file are only for prohibiting
    > other servers to sync with this one, so it looks ok to me?


    No, that's definitely not okay.

    All those servers have a reach of 377 (or almost), which is good.
    Time is getting from them to you. But it's about 350 seconds off.
    Actually, *you*'re probably 350 seconds off. And because you've
    told your NTP that the local clock knows best, it's believing (and
    serving) that.

    Either remove the local clock, or set your clock closer to good time
    before allowing NTP to start, or tell NTP to accept a large step
    once at startup.

    The first option may result in NTP consistenly dying shortly after
    startup. IIRC, the maximum step it will take is 1000 seconds. You
    are below that, so NTP may actually survive. Or not. Check.

    The second option can be facilitated with a manual sntp/ntpdate
    command, or with a list of NTP servers to poll for an automatic
    sntp/ntpdate command as part of the NTP subsystem startup. Read
    your startup scripts; /etc/step-tickers is where old Red Hat
    distributions look (don't take my word for it, take grep's).

    The third option is spelled '-g' on the command line that starts
    the ntpd process. Read the documentation.

    Groetjes,
    Maarten Wiltink



  3. Re: clock keeps getting behind, driftfile is 0.000

    On 2008-05-28, chantal@antenna.nl wrote:
    >
    >> chantal@antenna.nl writes:
    >> chantal> Hi list, the time on one of our servers is incorrect despite using
    >> chantal> ntpd, I also noticed that the driftfile value is 0.000 and doesn't
    >> chantal> changed. What could be the problem?
    >> chantal> Here is our conf file:
    >>
    >> Please read http://support.ntp.org/Support/AccessRestrictions .
    >>
    >> You can use 'ntpq -p' to see if you are syncing to any machines.

    >
    > Hi this, is the ntpq -p output:
    >
    > [root@server ~]# ntpq -p
    > remote refid st t when poll reach delay offset jitter
    >================================================== ==========================
    > sectionzero.org 35.65.96.0 3 u 171 1024 376 2.065 347330. 4621.34
    > steghoefer.eu 87.239.10.190 3 u 200 1024 377 2.182 351371. 4446.79
    > nieuwland-240.c 213.136.12.53 3 u 132 1024 377 0.728 347218. 4448.43
    > fw-enschede-6.i 193.190.230.65 2 u 201 1024 377 5.566 346919. 4457.15
    >*LOCAL(0) .LOCL. 10 l 33 64 377 0.000 0.000 0.001


    The problem here is that your ntpd is following the (fake) Undisciplined
    Local Clock instead of the (real) Remote Time Servers.

    The Undisciplined Local Clock is a kludge to allow an ntpd to claim to
    be synchronised even when it isn't. This capability is only useful if
    the ntpd is serving time to others. But, as you can see, undesireable
    things can happen.

    Please try commenting out the local clock and restarting ntpd. You may
    want to run 'ntpd -gq' before starting ntpd in daemon mode to preset the
    time.

    --
    Steve Kostecke
    NTP Public Services Project - http://support.ntp.org/

+ Reply to Thread