[BlueOnyx:07376] Re: Dovecot shutting down

[Gregg]

Thanks for all the info. 

Sent from my iPhone

On May 24, 2011, at 8:12 PM, Greg Schiedler <greg at limo.net> wrote:

> Install VMware tools.  And sync the VM to the host and the host to a reliable time source problem solved.  VMware tools is a bit tricky the first go around but once you learn the trick your good to go.  The install will fail if called directly  ie.  ./install.pl    but perl install.pl works like hot butter.
> 
> http://www.thoughtpolice.co.uk/vmware/howto/centos-5-vmware-tools-install.html
> 
> Should get you on your way.
> 
> I have a BO box on ESXi without any issues.
> 
> Greg
> 
> On Tue, May 24, 2011 at 5:23 PM, Michael Stauber <mstauber at blueonyx.it> wrote:
> Hi Gregg,
> 
> > dovecot: Fatal: Time just moved backwards by 13 seconds. This might cause a
> > lot of problems, so I'll just kill myself now.
> >
> > The problem is, it takes dovecot a lot longer than 13 seconds to come back
> > on, sometimes more than 30 minutes. Is there a way for me to have the
> > dovecot process come back up any sooner?
> 
> Your server is probably tied into an NTP server to automatically set the
> clock. Which all works fine. But your clock is drifting and whenever the NTP
> server "fixes" it by setting it to the correct time again, there is a more or
> less spectacular "jump" (like 13 seconds in your example). Which is enough to
> let Dovecot fall flat on its face.
> 
> Active Monitor runs every 15 minutes to check all enabled services to see if
> they're running. So within 15 minutes at the most Dovecot should then be
> restarted automatically. That *may* fail first time around, but gets fixed
> during the 2nd Active Monitor run another 15 minutes later.
> 
> How to fix this? Well, the best way ought to be to find out what makes the
> servers hardware clock go drifting and to fix that. Under VMware virtual Linux
> machines are known to have drifting clocks and there are some fixes available,
> which I cannot recall, as I usually avoid VMware like the plague.
> 
> If it's a physical server, I would consult the motherboard manual and possibly
> the vendor support site for more info.
> 
> At the worst you could try to fight the symptoms by either running the
> synchronization with the NTP server more frequently (so that the "jumps"
> aren't so massive). Or you could try to run the Active Monitor cronjob more
> frequently. That however creates too much overhead, as you don't really need
> to check every service like once a minute.
> 
> So in that case a custom cronjob that just checks Dovecot (and restarts it if
> need be) could be a work around.
> 
> But like said: Best would be to fight the cause, not to doctor with the
> symptoms.
> 
> --
> With best regards
> 
> Michael Stauber
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
> 
> 
> 
> -- 
> *** Limo.Net Internet Services ***
> *** 777-Host.Com ***
> 
>        \\\|///
>      \\  - -  //
>       (  @ @  )
> +---oOOo-(_)-oOOo---------------------------+
> | Greg Schiedler
> | Limo.Net Internet Services
> | PO Box 2249
> | Bethel, AK 99559-2249
> | 541.926.2009/503.328.2009/800.767.3932
> | Fax: 888.777.6120
> |
> |   ooo0         http://www.Limo.Net
> |  (   )    0ooo E-Mail: Greg at Limo.Net
> +---\ (-----(   )---------------------------+
>      \_)     ) /
>             (_/
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20110524/161f147b/attachment.html>