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?

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.
Parents
  • Okay, so I killed the HTTP proxy and the SOCKS5 proxy and NTP started working again. No reboot, no nothing.

    It looks like there is a fundamental problem with the packet processing (that interferes with other functions of the Astaro server) that for me is worse in 7.1 vs. 7.011.

    Even a moderate load on Astaro will cause issues in other services. Also if the CPU spikes due to 'admin-reporter.' hogging one CPU to the tune of 90-100% then there are other problems. 

    It is like Astaro is running a denial of service attack on itself [:S]

    So the lesson here is to image the Astaro box before doing a firmware upgrade. For me, 7.1 is a downgrade.
  • Something does seem to be amiss with NTP or its interaction with the hardware clock. I have 2 older IBM 8310 PCs, one running SuSE 9 (with NTP running) and one with Astaro 7.1 (setup with an NTP source) and I have swapped the hardware between the 2 and the problem follows the Astaro. They are both setup to access the same external Internet NTP source.

    The Astaro box kept semi-locking up, the Webadmin didn't want to load, you couldn't get a console login to work, I couldn't get a PPTP connection to complete but NAT functions allowing OWA access and email was passing through. I am not using the HTTP proxy, just the SMTP proxy. When I would restart the system and look at any reports there would be a large gap in time like the system had quit logging.

    What I discovered was that the system was jumping back in time and I assume that NTP couldn't handle it. I have removed all NTP Server entries and the lockup problem is gone but last night the system jumped back 13 hours (I'm using US Eastern time if that helps solve the problem). Remember, this same hardware did not have the problem with the SuSE NTP so it has something to do with the Astaro. It may have something to do with the IBM 8310 and Astaro becvause I have other hardware that doesn not have the problem but I've tried BIOS updates with no change to the problem.

    I also know that the system doesn't lose time, I check during the day, it jumps back by hours, the min. remain correct. I can't say it always happens at night but that is when I catch it because I won't have an Executive Report in the morning and when I connect to the system I discover it is because the system time hasn't reached the end of the previous day yet.

    I hope all this deatil helps.
  • Astaro Support told me that it's a bug in the latest linux NTP client package, so they can't do anything until the maintainers of that ntp package fix the problem.

    See if you can't get them to reference that bug upstream.

    I've got dozens of Linux boxes here all running NTP without any issue at all - they all stay well within a second of each other.

    I'm not sure what bug Astaro may be running in to, but it should be easily solved by moving to a different version. The fact that they also only let you sync to one NTP server does not help - you really should be using at least two - possibly three or four.

    Syncing to a single random NTP server will generally not be very reliable unless your connection to is also very reliable - and when you're pulling a random NTP server out of a hat (using pool.ntp.org) that is not very likely.
  • Hi there, 

    this is interresting. 

    MSchenk, can you please send me a note who from astaro support told you that information about a bug in the NTP client package, as i don't find an entry in our bugtracking system and hardly believe that is an issue there. thx

    We actually do have a shortcomming, which is that we only select a single ip from the hostname pool and sync against this one. 
    i'll check if this can be improved. 

    thanks
    Gert
  • We actually do have a shortcomming, which is that we only select a single ip from the hostname pool and sync against this one. 
    i'll check if this can be improved. 

    If we could define at least two NTP servers and preferably up to four that would be great. Thanks Gert!
  • Here's the support Case concerning this issue: (GERMAN)


    Case #00055117: astaro time sync funktioniert nicht richtig

    --------------------------------------------------------------------------------

    Case Details

    --------------------------------------------------------------------------------

    Status: Issue resolved

    Company:  
    Type: Issue 
    Reason: Not an Astaro Issue 
    Opened: 16 Oct 2007 
    Closed: 26 Oct 2007 
    License: ASL7 250 
    Product: Astaro Security Gateway Software 
    Software Version: 7.009 
    Support Level: silver 
    Category: Hardware 
    Priority: Medium 
    Description: Wenn wir unter "Management - System Settings - Time and Date - Synchronize time with internet server" einen NTP Server eintragen (Lokaler Server mit DCF77 Uhr) dann funktioniert auch die Zeitsynchronisation erst, aber trotzdem ist nach ca. 2 Wochen die Zeit 15 min hinterher. Geht man wieder in die Einstellungen und klickt "apply" dann wird wieder die "richtige" Uhrzeit aktiv. Dieses sollte aber automatisch funktionieren? 
     
    ---

    See "Support case Closed" plus the reason "Not an Astaro Issue"

    This is what i got from the astaro tech support as mail response:

    ->

    Guten Tag Herr Schenk,

    Ich habe neue Informationen zu diesem Problem. Leider muss ich ihnen mitteilen, dass sich dieses Problem im Moment nicht beheben lässt. Ursache ist, dass dies ein Fehler in der eingesetzten NTP Version ist.

    Leider müssen wir hier abwarten, bis dieser Fehler durch den Maintainer von ntp gefixt ist.


    Mit freundlichen Grüssen

    Nils Schiele  | Support Engineer Astaro AG | www.astaro.de | Phone +49-721-25516-0 | Fax +49-721-25516-200 | Amalienbadstrasse 36 / Bau 33a | 76227 Karlsruhe | Germany

    Download your free 30 day trial version of the award-winning Astaro Security Gateway solution here: https://my.astaro.com/download/

    ------

    Translated to english this states exactly what i wrote in one of the above posts.
  • My NTP server in ASL 7.104 is 2 minutes off, both on the firewall itself, and all the PCs syncing to it.

    I ran PS, and ntpd is running.

    There is nothing in the logs about ntp, and nothing with port 123 in the packetfilter log.

    I have the firewall set to use the "NTP server pool".

    Barry
  • If you log in to the console or ssh as root and run "ntpq -p", what does the output look like?

    It's probably one of two things:

    1. The time server you happened to get from the pool is not actually running.
    2. The time of your server's time was too different than the time on the pool and ntp won't sync up.

    #1 would be fixed if you could specify multiple NTP servers to sync to.
    #2 should be fixable by adding -g to the startup option to ntpd.

    Edit:

    I just checked one of my v7 servers and it's not good.

    # ntpq -p
    
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *127.127.1.0     .LOCL.          10 l   59  128  377    0.000    0.000   0.004
     12.110.191.46   64.202.112.75    2 u 296m   9h  377   80.971  54559.0 2381.82

    For some reason ntpd is preferring the local clock even when the server it is supposed to be syncing to is of a much lower stratum.

    Time has drifted 55 seconds off the reference clock as well.

    I'll have to go dig into the logs to see what I can find...
  • OK, in the logs I am seeing ntpd errors:

    "kernel time sync error 0001"

    A quick google of the phrase shows that it's a bug in the Linux kernel. The result of the bug is that time starts falling out of sync.

    I don't think that my earlier two suggestions will fix this problem. The kernel needs to be patched.

    This could be fixed in the beta release - anyone check?
  • I don't have those errors, but I do have a similar (worse) output from ntpq:


    # ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *LOCAL(0)        .LOCL.          10 l   82  128  377    0.000    0.000   0.002
     gallifrey.chpc. 209.132.176.4    2 u  41m   9h  377   71.834  -122985 1392.08

    fw:/var/log # grep -i "kernel time" *.log
    (no output)


    Barry
  • Yep, your ntp daemon is preferring the local clock vs the ntp server as well. I wonder why...
  • I have not used the ntpd in Astaro, but have been running chrony on a small 300Mhz P2 for years now.  I point all my equipment to it, Cisco, MS AD, other appliances and it just seems to work.  

    I would definitely recommend chrony in case you wanted to try something different, has a nice control app - chronyc which lets you see the clients that requested time from it and a verbose status of the time sync.
Reply
  • I have not used the ntpd in Astaro, but have been running chrony on a small 300Mhz P2 for years now.  I point all my equipment to it, Cisco, MS AD, other appliances and it just seems to work.  

    I would definitely recommend chrony in case you wanted to try something different, has a nice control app - chronyc which lets you see the clients that requested time from it and a verbose status of the time sync.
Children
No Data