Bug 811485

Summary:	dovecot service does not properly restart after reboot
Product:	[Fedora] Fedora	Reporter:	Daniel <daniel>
Component:	dovecot	Assignee:	Michal Hlavinka <mhlavink>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	janfrode, mhlavink
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-11 09:32:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Daniel 2012-04-11 08:53:02 UTC

Description of problem: After rebooting a server with installed dovecot. I let dovecot restart with "systemctl enable dovecot.service" after reboot. This automaticly starts the process "/usr/sbin/dovecot -F" and some child processes like dovecot/anvil, dovecot/log and dovecot/config.

Connecting to the server produces in /var/log/maillog

dovecot: master: Warning: Time moved backwards by 3526 seconds, waiting for 180 secs until new services are launched again.
dovecot: log: Warning: Time moved backwards by 3526 seconds.
dovecot: config: Warning: Time moved backwards by 3525 seconds.
dovecot: anvil: Warning: Time moved backwards by 3526 seconds.

and I can't retrieve any messages. Only after restart of the dovecot service via "/bin/systemctl restart dovecot.service" it works properly.

Version-Release number of selected component (if applicable): dovecot-2.0.19-1.fc16.x86_64

Comment 1 Michal Hlavinka 2012-04-11 09:32:07 UTC

If time moved backwards, it's expected behavior (from dovecot documentation):


Dovecot v2.0 finally tries to handle this a bit more gracefully. Its behavior when time moves backwards is:

    Existing imap and pop3 processes either sleep or die, just like with older versions
    Master process stops creating new processes until either the original time is reached, or after a maximum wait of 3 minutes.
    Other processes log a warning, but do nothing else.
    Timeouts are updated so that the timeout is executed approximately at the original intended time.