Bug 811485 - dovecot service does not properly restart after reboot
dovecot service does not properly restart after reboot
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Hlavinka
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-04-11 04:53 EDT by Daniel
Modified: 2012-04-11 05:32 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-11 05:32:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel 2012-04-11 04:53:02 EDT
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 05:32:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.