At 11:31 AM +0400 5/13/08, Eugene wrote:
Hi Timo,
From: "Timo Sirainen" tss@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 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
bill@scconsult.com