On Apr 8, 2007, at 11:00 AM, Bill Cole wrote:

At 7:25 PM +0200 4/8/07, Chaos Engine wrote:

...

Hi there, I got a daily cron (rdate to local time server) job wich adjusts
time and which constantly gives me headache.

Which is one reason (out of many) NTP was invented. :-)

...

Every day my dovecot suicides with:

"dovecot: Time just moved backwards by 11 seconds. This might
cause a lot of problems, so I'll just kill myself now."

Of course my onboard clock is constantly off by more than 5 secs.

How "of course?"

The last time I had a machine's NTP synch stop working, it diverged
less than 2 seconds from reality in a week. Looking at a few
machines where the LOM cards have RTC's independent of the
motherboard RTC's, I see divergence of 0-4 seconds over the past 2
months.

MANY cheap PC RTCs drift like a log on the ocean in a hurricane. The
fact you mention a LOM card sort of indicates you might be looking at
a Sun or the like. Their clocks are better.

...

I don't want to abandon time synchronization and I want to use dovecot.

Frankly, using 'rdate' is not time synchronization. It's time
*setting* on a regular basis. It's like calling 'time' on the phone
every few minutes/hours and setting your watch to what it says. And
what you are rdating you clock to? Another machine that has a
drifting RTC? NTP has the concept of tiers, so you can trust the
Atomic Clock above the GPS Clock above the machine you think is
pretty good, which in turn is above you (broken, but better than
nothing) RTC.

...

Maybe a -HUP signal would do? What do you propose?

3 options

1. Repair your hardware. Gaining 5 seconds per day is not normal,
   and really should not be tolerated in a system that has to converse
   with other machines.

Not always an option. :-)

2. Set up something that will do the adjustment for you on a more
   continuous basis. Xntpd will track your drift and keep you more in
   sync on a continuous basis by slewing the clock rather than
   stepping it back daily.

NTP is a LOT smarter than anyone realizes. It's best to use this,
because MANY *really smart* people have invested more time than is
reasonable in solving way more problems than you'll even encounter
running a machine.

3. Make that cron job smarter but stopping Dovecot (and anything
   else that might care about time moving backwards) ahead of the
   change, and then waiting until your clock is back ahead of that to
   restart them.

There are technical strategies (e.g. Maildir naming) which rely on
the assumption of the clock never repeating the same second twice.

It's not just dovecot, by the way. MANY things don't like have time
move backward, like Cron, at, etc. You should *NEVER* have the clock
jump back in time (except during DST changes -- yuk).

The correct way to handle time on Unix systems is to set the clock at
boot (rdate, ntpdate, etc), and then *skew* the clock, so time slows
down to match the right time. It can always jump forward, but NTP
only jumps by a (settable) maximum amount per time-quantum. This
prevents things like make, and NFS caching, and a bunch of other
stuff "just work".

As far as I know, all shipping OSes now have a working NTP client,
and it's VERY easy to just add

server pool.ntp.org

to the ntpd.conf file, and you're good to go on reboot.

Sean

On Apr 8, 2007, at 2:20 PM, Bill Cole wrote:

...

You should *NEVER* have the clock jump back in time (except during
DST changes -- yuk).

DST changes (at least on sane systems) do not change the system
clock time. Time zones are a cosmetic feature, i.e. how humans are
shown a description of time. For example, the following are
different ways of displaying exactly the same time:

12:03 PM -0700 4/8/07 15:03 PM EDT 4/8/07 14:03 PM EST 4/8/07 19:03 PM -0000 4/8/07 00:03 PM +0500 4/9/07

I'd just like to publicly proclaim that I'm an idiot. I knew that.
And it wasn't even at 4am, which is my usual excuse. This after two
to three weeks of the stupid DST change here in the US.

It is important for people to understand how much simpler it is now
to run basically functional and non-abusive NTP than it was even 5
years ago. The work put into making pool.ntp.org usable has
essentially eliminated the need to think much about NTP for most
sites.

Absolutely! It's been standard on Macs for some time (it's how it
syncs with time.apple.com, etc). It's just braindead easy for one or
two machines. If you have more than that, making one or two machines
as broadcast/multicast servers and having everything use them is
straightforward, too.

Sean

2007/4/17, Michal Soltys nozo@ziu.info:

Chaos Engine wrote:

...

Of course my onboard clock is constantly off by more than 5 secs. I don't want to abandon time synchronization and I want to use dovecot. Maybe a -HUP signal would do? What do you propose?

Not too long ago there was a similar question. You can simply recompile dovecot with one of the defines changed to whatever is going to suit you (putting aside that ">constantly off by 5 sec" is just ... strange).

Thank you all for responses. I probably drop rdate and use some ntp client. Or I expireiment with hwclock and /etc/adjtime. The problem with rdate arises after some version bump and I thought this method was pretty safe and correct

-- Chaos greets U