I just did a "dnf update" and now dovecot won't start at boot.
I get errors like:
Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Main process exited, code=exited, status=89/n/a Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Unit entered failed state. Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Failed with result 'exit-code'.
And over in maillog for the same timestamp:
Feb 11 07:23:41 tomh dovecot: master: Error: service(imap-login): listen(*, 993) failed: Address already in use Feb 11 07:23:41 tomh dovecot: master: Fatal: Failed to start listeners
But if I manually do this a few minutes after I boot:
sudo systemctl restart dovecot.service
It then starts running with no problems.
So who the heck is grabbing the imap ports when dovecot tries to start at boot?
On 02/11/16 20:35, Tom Horsley wrote:
I just did a "dnf update" and now dovecot won't start at boot.
I get errors like:
Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Main process exited, code=exited, status=89/n/a Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Unit entered failed state. Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Failed with result 'exit-code'.
And over in maillog for the same timestamp:
Feb 11 07:23:41 tomh dovecot: master: Error: service(imap-login): listen(*, 993) failed: Address already in use Feb 11 07:23:41 tomh dovecot: master: Fatal: Failed to start listeners
But if I manually do this a few minutes after I boot:
sudo systemctl restart dovecot.service
It then starts running with no problems.
So who the heck is grabbing the imap ports when dovecot tries to start at boot?
If you are certain the problem arose after the most recent update then the logical thing to do is list what was updated. Then, either downgrade them all or do it selectively to see if you can revert to a working condition.
Also, you said "a few minutes after" you boot it manually restarts just fine. Does that mean there was a time prior to those few minutes where a manual start failed?
On Thu, 11 Feb 2016 22:05:32 +0800 Ed Greshko wrote:
If you are certain the problem arose after the most recent update then the logical thing to do is list what was updated.
I'm not certain of anything any more :-).
I rebooted twice after the update and dovecot failed each time, so it seemed to be reproducible, but then I added a "netstat -n -l -p" command to dovecot's "pre start" script so I could see who has port 993 tied up when dovecot starts, and it has worked perfectly after the reboots I tried with the modified the script.
I haven't yet tried putting back the original script to see if it starts failing again because I'm tired of rebooting :-).
On Thu, Feb 11, 2016 at 1:35 PM, Tom Horsley horsley1953@gmail.com wrote:
I just did a "dnf update" and now dovecot won't start at boot.
No issue here with the updated dovecot. I guess it has nothing to do with the update.
I get errors like:
Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Main process exited, code=exited, status=89/n/a Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Unit entered failed state. Feb 11 07:23:41 tomh systemd[1]: dovecot.service: Failed with result 'exit-code'.
And over in maillog for the same timestamp:
Feb 11 07:23:41 tomh dovecot: master: Error: service(imap-login): listen(*, 993) failed: Address already in use
This above line means the socket is already up and listening. Dovecot systemd service file is bind to <dovecot.socket> unit. Stopping only dovecot is not enough, the socket must be closed to.
Feb 11 07:23:41 tomh dovecot: master: Fatal: Failed to start listeners
What is the output of <$ systemctl status deovecot -l> when dovecot is down ? Did you have a look at <dovecot-init.service> ?
But if I manually do this a few minutes after I boot:
sudo systemctl restart dovecot.service
Try this instead:
# systemctl stop dovecot # systemctl stop dovecot.socket # systemctl start dovecot
The restart command is not always the safest choice.
It then starts running with no problems.
So who the heck is grabbing the imap ports when dovecot tries to start at boot?
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Is portreserve installed and doing things?
I had the opposite problem with Centos 6.7 dovecot was grabbing the port when I didn't want it to
From my DIY notes
To cure the /etc/portreserve/dovecot problem on maui the immutable bit has been set on an empty file chattr +i /etc/portreserve/dovecot
On Thu, 2016-02-11 at 10:16 -0500, Tom Horsley wrote:
On Thu, 11 Feb 2016 22:05:32 +0800 Ed Greshko wrote:
If you are certain the problem arose after the most recent update then the logical thing to do is list what was updated.
I'm not certain of anything any more :-).
I rebooted twice after the update and dovecot failed each time, so it seemed to be reproducible, but then I added a "netstat -n -l -p" command to dovecot's "pre start" script so I could see who has port 993 tied up when dovecot starts, and it has worked perfectly after the reboots I tried with the modified the script.
I haven't yet tried putting back the original script to see if it starts failing again because I'm tired of rebooting :-).
On Thu, 11 Feb 2016 16:20:45 +0100 arnaud gaboury wrote:
# systemctl stop dovecot.socket
What in the blue blazes is dovecot.socket for? That sounds like something I'd use to have systemd start dovecot dynamically when someone tries to access the port.
It is disabled on my system. It has always been disabled. systemctl status says it is inactive.
I'd expect to get the error about the port being in use if I enabled it because then systemd would indeed be listening on the ports dovecot wants to listen on.
-
arnaud gaboury -
Dr J Austin -
Ed Greshko -
Tom Horsley