problem sync time in client ntpd when server ntpd is restarted. - NTP

This is a discussion on problem sync time in client ntpd when server ntpd is restarted. - NTP ; Hi, can any one help with the problem sync time in client ntpd when server ntpd is restarted with different settings. i have manually set time in server ntpd and able to serve time to client ntpd with out problem, ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: problem sync time in client ntpd when server ntpd is restarted.

  1. problem sync time in client ntpd when server ntpd is restarted.

    Hi,
    can any one help with the problem sync time in client ntpd when
    server ntpd is restarted with different settings.


    i have manually set time in server ntpd and able to serve time to
    client ntpd with out problem, after some time i restart my server nptd
    by giving a public ntp server address to sync and succeeds. Now this
    new time is not syncing properly with client ntpd or many times client
    ntpd stops abrubtly. when i restart client ntpd it is syncing properly
    with new time.

    can any one guide me to properly sync client ntpd with out restarting
    it, when server ntpd restarts.


    ntp.conf in server for manual time setting
    #NTP configuration file
    server 127.127.1.0 iburst minpoll 4 #use local clock as bkup or manual
    time
    fudge 127.127.1.0 stratum 10 #reduce stratum for local clock
    restrict default nomodify notrap nopeer restrict 127.0.0.1 #restirct
    loopback
    restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap #serve lan
    clients
    driftfile /etc/ntp/drift
    logfile /var/log/ntp.log
    #end of NTP config file

    ntp.conf in server for public ntp server
    #NTP configuration file
    server 213.246.63.72 burst iburst minpoll 4
    server 127.127.1.0 iburst minpoll 4 #use local clock as bkup or manual
    time
    fudge 127.127.1.0 stratum 10 #reduce stratum for local clock
    restrict default nomodify notrap nopeer restrict 127.0.0.1 #restirct
    loopback
    restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap #serve lan
    clients
    driftfile /etc/ntp/drift
    logfile /var/log/ntp.log
    #end of NTP config file


    ntp.conf in client
    #NTP configuration file
    server 192.168.0.1 burst iburst minpoll 4
    server 127.127.1.0 iburst minpoll 4 #use local clock as bkup or manual
    time
    fudge 127.127.1.0 stratum 10 #reduce stratum for local clock
    driftfile /etc/ntp/drift
    logfile /var/log/ntp.log
    #end of NTP config file

    thanks in advance

    murugan


  2. Re: problem sync time in client ntpd when server ntpd is restarted.

    muruga wrote:
    > Hi,
    > can any one help with the problem sync time in client ntpd when
    > server ntpd is restarted with different settings.
    >
    >
    > i have manually set time in server ntpd and able to serve time to
    > client ntpd with out problem, after some time i restart my server nptd
    > by giving a public ntp server address to sync and succeeds. Now this
    > new time is not syncing properly with client ntpd or many times client
    > ntpd stops abrubtly. when i restart client ntpd it is syncing properly
    > with new time.
    >
    > can any one guide me to properly sync client ntpd with out restarting
    > it, when server ntpd restarts.
    >



    Ntpd has a "panic" threshold of 1024 seconds and will exit if it finds
    the time in error by that much or more!

    Ideally, you should not be serving your unshnchronized local clock.
    Some people do it but, although it will sometimes keep a bunch of other
    computers more or less in synchronization, there is no guarantee that
    the time is even close to being correct! The synchronization may not be
    very close either; think of one drunken driver tying to follow another!

    If you are having problems keeping your server synchronized, post the
    output of ntpq -p.

    Note that, while a single external server will work, it is a
    configuration that is far from robust! If the server dies your clock is
    unsynchronized. If the server is wrong, your clock is wrong. Etc.
    Four servers are generally regarded as the minimum required for reliability.


+ Reply to Thread