NTP broken with 7.1?

On my side, i keep having problems with NTP on the Astaro. NTP is configure to sync with O.be.pool.ntp.org, but i have to adjust time manually quite ofen. I did it today as the astaro was 10 minuts to late... I don't understand how it's possible! 
Or the sync doesn't work and the system clock is quite buggy, or the sync is working but the ntp.org time is not correct...

Any idea???

We have the same issues, with NTP on astaro only working one time when you hit apply in ntp settings. After a week it may happen that Astaro is 10 minutes late. We're using our own time server to synchronise (dcf-77 atom time) so it's not the time server to blame here. I noticed these problems with the initial release of V7. Also created a bug report. 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.

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