NTP broken with 7.1?

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.

If you do an "ntpdate -q tock.usno.navy.mil" does it get time from tock and show the difference?

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

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.

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.

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

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

Barry, I'm not seeing this - are you sure you have a packet filter rule allowing NTP to go out?

Cheers - Bob

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

I agree that the Astaro doesn't need a PF for its own NTP traffic, but I see outbound NTP traffic logged by a PF rule ('Internal (Network)' -> 1:1024 -> 'Any') I use to see what traffic I need to allow.

If you configure Windows to use an external time server, I'm pretty confidant you need to open port 123.  If you're saying the Astaro is serving time, then I'd like to know how to do that.

Thanks - Bob

If you're saying the Astaro is serving time, then I'd like to know how to do that.

Yeah, ASL7 has an NTP server... it's in webmin somewhere, and then I just tell windows in the time settings to use the internal firewall IP as the timeserver.

Barry

If you're saying the Astaro is serving time, then I'd like to know how to do that.

Yeah, ASL7 has an NTP server... it's in webmin somewhere, and then I just tell windows in the time settings to use the internal firewall IP as the timeserver.

Barry