At 11:31 AM +0400 5/13/08, Eugene wrote:
Hi Timo,
From: "Timo Sirainen" <[EMAIL PROTECTED]>
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
me..
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
accommodate
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
breakage yourself.
--
Bill Cole
[EMAIL PROTECTED]
