Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 52 replies
  • Subscribers 2 subscribers
  • Views 21091 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NTP broken with 7.1?

proxyagenda
I have setup Astaro 7.1 as an NTP server. With 7.011 NTP was reliable (except when running BitTorrent).

Now with 7.1, the NTP server seems to die occasionally/often and my NTP client tells me "server is insane" -- i.e. the time returned from the NTP server doesn't make sense. It seems like NTP will run for a bit and then die or go "insane".

Any tips on how to diagnose/fix the NTP server with 7.1? I've tried stopping/restarting it and rebooting.  Neither one fixes the problem.


This thread was automatically locked due to age.
  • 0 in reply to BarryG
    My clock is currently off by almost 9 minutes.
    (currently I'm running 7.202) 


    > ps auxw|grep ntp

    root      5696  0.0  0.2   3680  1180 ?        Ss   Sep19   0:01 /sbin/ntpd


    Nothing about ntp in todays logs.

    I'm going to try to open a support case about this too.

    Barry
  • 0 in reply to BarryG 

    # ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *LOCAL(0)        .LOCL.          10 l   18  128  377    0.000    0.000   0.002
     ntp.your.org    .CDMA.           1 u 118m   9h  377   77.404  513539. 7298.68
  • 0 in reply to BarryG
    If you do an "ntpdate -q tock.usno.navy.mil" does it get time from tock and show the difference?
  • 0 in reply to Jack Daniel
    Yes...  
    # ntpdate -q tock.usno.navy.mil

    server 192.5.41.41, stratum 1, offset 533.382912, delay 0.12167

    22 Oct 12:47:59 ntpdate[1947]: step time server 192.5.41.41 offset 533.382912 sec
  • 0 in reply to BarryG
    There appears to be a "difference of opinion" between the NTP folks and the Linux kernel folks. Short version- this is an issue for some systems which Astaro cannot fix readily.  This seems to primarily impact software installs, not ASG appliances.

    NTPD will sync at each start- so if this is a problem for you, an occasional restart of NTPD will adjust the time.
  • 0 in reply to Jack Daniel
    There appears to be a "difference of opinion" between the NTP folks and the Linux kernel folks

    This may be so, but this doesn't explain why none of my other Linux servers running various versions of CentOS and Fedora have never had any issues with ntpd. Any references to this "difference of opinon" and why Astaro is affected by this would be appreciated.

    As I mentioned in an earlier post, it appears to be a bug in the kernel that can be patched. If it's not patched in the latest v7 kernel, then it should be.

    And the fact that you can only specify one upstream ntp server to sync to is broken as well. You need to be able to specify between 2-4 (3 being typical) to get reliable time synchronization.
  • 0 in reply to drees 

    borgqueen:/home/login # ntpq -p                    

         remote           refid      st t when poll reach   delay   offset  jitter

    ==============================================================================

     LOCAL(0)        .LOCL.          10 l   93  128  377    0.000    0.000   0.002

    *ptbtime1.ptb.de .PTB.            1 u  390 1024  377   27.266   -1.045   0.240

    borgqueen:/home/login # ntpdate -q tock.usno.navy.mil

    server 192.5.41.41, stratum 1, offset 0.003006, delay 0.13274

    23 Oct 23:15:57 ntpdate[31496]: adjust time server 192.5.41.41 offset 0.003006 sec


    Gregor Kemter
  • 0 in reply to gkemter
    IIRC, Astaro already fixed the problem with NTPd not syncing correctly.

    Anyways, I'm still seeing regular errors in my windows event logs about w32time unable to sync:
    The time service has not been able to synchronize the system time for 49152 seconds because none of the time providers has been able to provide a usable time stamp. The system clock is unsynchronized.


    This is still happening with Astaro upgraded to 7.390 and WinXP upgraded to SP3.

    Thanks,
    Barry
  • 0 in reply to BarryG
    Barry, I'm not seeing this - are you sure you have a packet filter rule allowing NTP to go out?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Hi Bob, I shouldn't need a PF rule, as NTP is going from the XP client to the Astaro NTP server.

    I've done packet traces in WireShark before, in fact I posted one in this thread above somewhere, and the firewall is definitely responding to the NTP queries.
    And the client does update some of the time, but it's failing almost every day according to the event log on XP.

    Thanks,
    Barry
Cookie Information Banner