[Dovecot] Time moved backwards
dovecot-20061108 at billmail.scconsult.com
Tue May 13 16:48:42 EEST 2008
At 11:31 AM +0400 5/13/08, Eugene wrote:
>From: "Timo Sirainen" <tss at iki.fi>
>>>I suggest that Dovecot simply terminate the current connections (causing the
>>>client to reconnect) or -- if the time change is really that much of a
>>>problem -- to restart itself automatically.
>>I guess terminating all current connections and restarting all processes
>>would be pretty safe, but it's not really a high priority change for
>Nevertheless, it would be very nice if you could fix it. It's a
>fairly big availability problem (for us, at least).
Then you have a badly broken system. There is no explanation for time
going backwards on a server on a frequent unplanned basis that is not
reducible to administrative incompetence or malfunctioning hardware
(and the latter as a chronic issue can be seen as just a special case
of the former.)
>And after all, if we are terminating already, adding a simple spawn
>call before that should not take much time?
A system clock that moves backwards is indicative of a problem.
Having a service respawn itself as a response to a problem that is
outside of its control (i.e. the respawn is not itself a fix) is
begging for trouble, because that behavior has to be carefully
controlled to prevent it from contributing to a cascading problem. On
a system whose clock is untrustworthy, this is a significant
challenge. The effort to do that sort of code correctly just to
people with broken systems seems like a terrible waste.
On the other hand, writing a freestanding watchdog for a critical
service is (or at least should be) something any good sysadmin can
do. If you are stuck with hardware so broken that it jumps backwards
in time without warning but not so broken that you can get it
replaced, and it lives in a network or resource environment that
prevents you from fixing the core problem, you can adapt to the
bill at scconsult.com
More information about the dovecot