NTP set up in YAST is loosing time
Hi, I have used NTP in previous SUSE 9.X, but on 9.3 I used YAST to set up NTP. YASTs dialog says that it will sync to a time server at bootup. In the past I am sure that the local PC was re-sync'd quite often. I rarely ever saw a difference of more than a second between my "Atomic" wall clock or watch. But now I see the PCs time getting more and more 'off' the longer it has been booted. This is irritating and non-intuitive. The systems should stay in sync with the 'official' time servers. One should NOT have to re-boot just to get the clock back in sync. Is the a way to tell the system to regularly 'sync up'? Has anyone out there found a way to keep a 9.3 system time accurate? PeterB
Peter B Van Campen wrote:
Hi,
I have used NTP in previous SUSE 9.X, but on 9.3 I used YAST to set up NTP. YASTs dialog says that it will sync to a time server at bootup. In the past I am sure that the local PC was re-sync'd quite often. I rarely ever saw a difference of more than a second between my "Atomic" wall clock or watch.
But now I see the PCs time getting more and more 'off' the longer it has been booted. This is irritating and non-intuitive. The systems should stay in sync with the 'official' time servers. One should NOT have to re-boot just to get the clock back in sync.
Is the a way to tell the system to regularly 'sync up'? Has anyone out there found a way to keep a 9.3 system time accurate?
PeterB
Is your system running as guest on a VMware ESX-Server? I has problems
with this scenario synchronizing at all with 2.6.x-kernels.
Otherwise:
Does "ntpdate
Peter B Van Campen wrote:
Hi,
I have used NTP in previous SUSE 9.X, but on 9.3 I used YAST to set up NTP. YASTs dialog says that it will sync to a time server at bootup. In the past I am sure that the local PC was re-sync'd quite often. I rarely ever saw a difference of more than a second between my "Atomic" wall clock or watch.
But now I see the PCs time getting more and more 'off' the longer it has been booted. This is irritating and non-intuitive. The systems should stay in sync with the 'official' time servers. One should NOT have to re-boot just to get the clock back in sync.
Is the a way to tell the system to regularly 'sync up'? Has anyone out there found a way to keep a 9.3 system time accurate?
PeterB
There were problems with the some kernels around 2.6.10/11. http://www.ussg.iu.edu/hypermail/linux/kernel/0412.1/1319.html Recently the timeoday structure has changed in 2.6.12+, but before that, it's been reasonable. In 2.6.12-git10 I'm seeing between -1 and -3 secs drift. When it was really bad I had to set up cron to resync once a minute because ntp wasn't able to sync to the external server. Then I commented out "server 127.127.1.0" in /etc/ntp.conf, forcing sync to the external server, I just noticed I'm still running that way on this 9.3 x86 box. The Mandrake 10.1 and the 9.3 x86_64 laptops have always been rock solid. The Mandrake and 9.3 x86 boxes have the same motherboards. You don't need to reboot to get the time reset, ntpdate or build rdate from source will do that on the fly. I use ptktime to compare time. I'm getting the 0 drift just after I run rdate, must check a few hours later to see how much it's drifted. It was -3 secs after 7 hours uptime, now -1 sec after about 4 minutes. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Keen licensed Private Pilot Retired IBM Mainframes and Sun Servers Tech Support Specialist Microsoft Windows Free Zone - Linux used for all Computing Tasks
On Thursday 30 June 2005 02:18, Sid Boyce wrote:
Peter B Van Campen wrote:
Hi,
I have used NTP in previous SUSE 9.X, but on 9.3 I used YAST to set up NTP. YASTs dialog says that it will sync to a time server at bootup. In the past I am sure that the local PC was re-sync'd quite often. I rarely ever saw a difference of more than a second between my "Atomic" wall clock or watch.
But now I see the PCs time getting more and more 'off' the longer it has been booted. This is irritating and non-intuitive. The systems should stay in sync with the 'official' time servers. One should NOT have to re-boot just to get the clock back in sync.
Is the a way to tell the system to regularly 'sync up'? Has anyone out there found a way to keep a 9.3 system time accurate?
PeterB
There were problems with the some kernels around 2.6.10/11. http://www.ussg.iu.edu/hypermail/linux/kernel/0412.1/1319.html Recently the timeoday structure has changed in 2.6.12+, but before that, it's been reasonable. In 2.6.12-git10 I'm seeing between -1 and -3 secs drift. When it was really bad I had to set up cron to resync once a minute because ntp wasn't able to sync to the external server. Then I commented out "server 127.127.1.0" in /etc/ntp.conf, forcing sync to the external server, I just noticed I'm still running that way on this 9.3 x86 box. The Mandrake 10.1 and the 9.3 x86_64 laptops have always been rock solid. The Mandrake and 9.3 x86 boxes have the same motherboards. You don't need to reboot to get the time reset, ntpdate or build rdate from source will do that on the fly. I use ptktime to compare time. I'm getting the 0 drift just after I run rdate, must check a few hours later to see how much it's drifted. It was -3 secs after 7 hours uptime, now -1 sec after about 4 minutes. Regards Hi Sid,
Thanks for the reply. My Kernel is the current YAST provided update 2.6.11.4-21.7 and the same in the SMP flavor. The situation here is centered about the SUSE changes in the way service XNTPD handles time sync for the system. The YAST runlevel services editor is set to start xntpd to sync time upon boot, and this is observed being done. Also, I can observe the clock being updated when I use YAST to 'disable and re-enable' the service. But without manual intervention the clock is left to drift until the next boot. This may be fine for infrequently used systems that are booted each time the user wants to use them, but hell on those of us that leave them on all the time. Hi Michael, There is no VM involved on my systems. "ntpq -p" returns "ntpq: read: Connection refused" when the service is disabled and "No association ID's returned" when XNTPD is enabled. "ntptrace" returns "localhost: stratum 16, offset 0.000000, synch distance 0.002145" when XNTPD is enabled and "/usr/sbin/ntpq: read: Connection refused" when disabled. Sid, could you share your cron job to re-sync every minute. Or, is there a way to get the system to regularly re-sync? Thanks, PeterB
On Monday 04 July 2005 08:38 pm, Peter B Van Campen wrote:
Thanks for the reply. My Kernel is the current YAST provided update 2.6.11.4-21.7 and the same in the SMP flavor. The situation here is centered about the SUSE changes in the way service XNTPD handles time sync for the system. The YAST runlevel services editor is set to start xntpd to sync time upon boot, and this is observed being done. Also, I can observe the clock being updated when I use YAST to 'disable and re-enable' the service. But without manual intervention the clock is left to drift until the next boot. This may be fine for infrequently used systems that are booted each time the user wants to use them, but hell on those of us that leave them on all the time.
Hi Michael,
There is no VM involved on my systems. "ntpq -p" returns "ntpq: read: Connection refused" when the service is disabled and "No association ID's returned" when XNTPD is enabled. "ntptrace" returns "localhost: stratum 16, offset 0.000000, synch distance 0.002145" when XNTPD is enabled and "/usr/sbin/ntpq: read: Connection refused" when disabled.
Sid, could you share your cron job to re-sync every minute. Or, is there a way to get the system to regularly re-sync?
Thanks, PeterB
Running xntpd should re-sync periodically. Have never had a problem with it here. And certainly, syncing your clock every minute is very extreme. Try deleting the file: /etc/adjtime. This maybe causing your clock to drift since it sets up an amount of drift to correct when it sets the time. If if you clock was originally a ways off, it may have an overly large drift adjustment.
On Monday 04 July 2005 08:38 pm, Peter B Van Campen wrote:
Sid, could you share your cron job to re-sync every minute. Or, is there a way to get the system to regularly re-sync?
The command to use in your crontab would be: * 0,12 * * * ntpdate north-america.pool.ntp.org This will update your clock twice a day which should be plenty. -- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 07/04/05 20:57 + +----------------------------------------------------------------------------+ "If a mute swears, does his mother wash his hands with soap?"
this is a very bad idea to put an ntpdate in a crontab because : 1) a lot of ntpd server closed their public access because of that, because a lot of ntpdate synchronize not in a random manner but in a synchronised manner, at the same time. 2) the time can go back (set from 10:04:57 to 10:01:32), wich is critical for mail servers, if the drift is growing a lot, their may a reason, a hardware problem or a connection problem too, that's why it is important to set an indisciplined local clock first and when the clock is drifting a lot, the burst and iburst options can be set in order to force ntpd to increase the frequency of his adjustments. like : server 127.127.1.0 fudge 127.127.1.0 stratum 10 server 147.210.1.1 burst iburst // burst and ibirst to force a stronger //adjustment driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp.log
[Aldrik KLEBER]
this is a very bad idea to put an ntpdate in a crontab because : [...] 2) the time can go back (set from 10:04:57 to 10:01:32), which is critical for mail servers,
I'm curious. How or why would it be critical? -- François Pinard http://pinard.progiciels-bpi.ca
François Pinard wrote:
[Aldrik KLEBER]
this is a very bad idea to put an ntpdate in a crontab because : [...] 2) the time can go back (set from 10:04:57 to 10:01:32), which is critical for mail servers,
I'm curious. How or why would it be critical?
I'm not sure about mail servers, but the post office wants to ensure snail mail is properly aged, before delivery. ;-)
On Saturday 12 Nov 2005 19:05, James Knott wrote:
François Pinard wrote:
[Aldrik KLEBER]
this is a very bad idea to put an ntpdate in a crontab because : [...] 2) the time can go back (set from 10:04:57 to 10:01:32), which is critical for mail servers,
I'm curious. How or why would it be critical?
I'm not sure about mail servers, but the post office wants to ensure snail mail is properly aged, before delivery. ;-)
Yea i just wish they would not do it with my darn credit card bills that get me greif off of the bank then and more whingeing about late payments .. pete . -- If Bill Gates had gotten LAID at High School do YOU think there would be a Microsoft ? Of course NOT ! You gotta spend a lot of time at your school Locker stuffing underware up your ass to think , I am going to take on the worlds Computer Industry -------:heard on Cyber Radio.:------- AFFA
On Sat, 2005-11-12 at 14:05 -0500, James Knott wrote:
François Pinard wrote:
[Aldrik KLEBER]
this is a very bad idea to put an ntpdate in a crontab because : [...] 2) the time can go back (set from 10:04:57 to 10:01:32), which is critical for mail servers,
I'm curious. How or why would it be critical?
I'm not sure about mail servers, but the post office wants to ensure snail mail is properly aged, before delivery. ;-)
Rumor has it the practice started when a retired cheese maker was made postmaster. From then on the aged mail was preferred to the new mail. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2005-11-12 at 11:59 -0500, François Pinard wrote:
[Aldrik KLEBER]
this is a very bad idea to put an ntpdate in a crontab because : [...] 2) the time can go back (set from 10:04:57 to 10:01:32), which is critical for mail servers,
I'm curious. How or why would it be critical?
Many processes depend on timing. Queuing would go berserk for a while, for instance. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDe4nAtTMYHG2NR9URAsOtAJwOgCltITlktIFrUPDNVSI82TiEOACggrSR rw+p6JD2JnIlI1jZFb5XEhw= =1ix9 -----END PGP SIGNATURE-----
[Aldrik KLEBER]
this is a very bad idea to put an ntpdate in a crontab because : [...] 2) the time can go back (set from 10:04:57 to 10:01:32), which is critical for mail servers,
[François Pinard]
I'm curious. How or why would it be critical?
[Carlos E. R.]
Many processes depend on timing. Queuing would go berserk for a while, for instance.
Of course, processes may depend on timing. But this is a generality... What were the symptoms of "queues going berserk" which you observed? Or if you did not observe them yourself, maybe you are sharing with us some experience you've got for someone else? Or you might have read the source code, and telling us your analysis? For one, I do not know, so I'm not asserting anything here. But I'm interested in the experience of others. Short of this, the worst I could imagine for queueus is mail being delivered not always in the order of submission. But even if usual, this is not guaranteed to start with, so I hardly see anything critical here. So I still wonder what substantiates the original poster's assertion, about something being critical. -- François Pinard http://pinard.progiciels-bpi.ca
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-11-17 at 14:40 -0500, François Pinard wrote:
Many processes depend on timing. Queuing would go berserk for a while, for instance.
Of course, processes may depend on timing. But this is a generality...
What were the symptoms of "queues going berserk" which you observed? Or if you did not observe them yourself, maybe you are sharing with us some experience you've got for someone else? Or you might have read the source code, and telling us your analysis?
It wasn't me who said "critical". Yes, I have observed weird things when changing the time suddenly, specially if you change the date. If mail is pending, for instance, and the time jumps forward ahead of the allowed delay for delivery, the pending mail suddenly bounces back as undeliverable. Yo might not need days for this: if postfix is sending mails to a content filter, and it thinks they are taking more than half an hour to process them, it aborts; it might then bounce or send without filtering. The mta should/might cope with the inconveniences of small jumps, but I think you can understand that their queuing algorithms are thrown out of balance. As for time going back... well, for instance, spammassassin will note it and complain (DATE_IN_FUTURE_*). An email might be tagged as spam because of that. Or, depending on the algorithm used, emails might stay put till half an hour since the last try had passed, but as the time stamp would be in the future, it could be hours till real delivery. Or, if you are trying to analyze an event, something that went wrong, you have a quite harder time tracking what happened and in what order if one of the servers marks the time wrong. It could be "critical" depending on what you are analyzing. One thing you can easily observe is what happens with cron jobs. I tried. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDfdLPtTMYHG2NR9URAolbAJ9LVbsr8Gc1p7skBEhU76xMCba2uACfdFLu o3+dh2/0efj/jwUjYORFaiA= =EuAb -----END PGP SIGNATURE-----
[Carlos E. R.]
[...] pending mail suddenly bounces back as undeliverable. [...] postfix [...] content filter [...] aborts [...] spammassassin will [...] complain (DATE_IN_FUTURE_*). [...] be hours till real delivery. [...] harder time tracking what happened and in what order
Interesting observations. Thanks for sharing them! -- François Pinard http://pinard.progiciels-bpi.ca
participants (10)
-
Aldrik KLEBER -
Bruce Marshall -
Carl William Spitzer IV -
Carlos E. R. -
François Pinard -
James Knott -
Michael Behrens -
Peter B Van Campen -
Peter Nikolic -
Sid Boyce