Description of problem: Since some recent update, dovecot fails to startup after bootup: # systemctl status dovecot.service dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/etc/systemd/system/dovecot.service; enabled) Active: failed (Result: exit-code) since Mon, 05 Nov 2012 10:58:58 +0100; 1min 48s ago Process: 849 ExecStart=/usr/sbin/dovecot -F (code=exited, status=89) CGroup: name=systemd:/system/dovecot.service Nov 05 10:58:58 beck dovecot[849]: Error: service(imap-login): listen(*, 993) failed: Address already in use Nov 05 10:58:58 beck dovecot[849]: master: Error: service(imap-login): listen(*, 993) failed: Address already in use Nov 05 10:58:58 beck dovecot[849]: Fatal: Failed to start listeners Nov 05 10:58:58 beck dovecot[849]: master: Fatal: Failed to start listeners ... Version-Release number of selected component (if applicable): dovecot-2.1.10-1.fc17.x86_64 How reproducible: No idea. Additional info: <rant> Seems to me, as if the old port allocation bugs, which had been haunting Red Hat distros for many years are back </rant>
What listens on that port? netstat -lnp | grep 993
(In reply to comment #1) > What listens on that port? > netstat -lnp | grep 993 Well, no idea what was listening when this issue had happened. I restarted dovecot after dovecot didn't come up (without rebooting). Now (Still, not having rebooted since), dovecot is listening: # netstat -lnp | grep 993 tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 1741/dovecot tcp6 0 0 :::993 :::* LISTEN 1741/dovecot I am pretty much clueless about what might be going on - systemd, SELinux, UsrMove?
The bug is in glibc: bindresvport() it takes random privileged ports. When dovecot wanted to start, port was already used by some service. One of the most often used services with bad behavior is NFS. There is a way to fix that bug #456401, but upstream refused to apply the fix. Semi-working workaround is to use portreserve, but the bug is in different component. Also it's a bad workaround. Dovecot uses imap, imaps, pop3, pop3s and sieve, but there are different services that use these ports. For example cyrus-imapd. There can be setup where cyrus-imapd serves imap(s) protocol and dovecot pop3(s) protocol. What ports should dovecot release before start? Also when both cyrus-imapd and dovecot are running and dovecot does not run on standard ports. What here? For whatever reason we started fixing (adding only semi working ugly workarounds) in all affected applications instead fixing the one that is buggy. Just recently, I found another case, where this so called solution fails. When service stops (or dies) port is no longer reserved, so when you try to start it again, it's not guaranteed that the port is still available. It's sad situation, but there is not much to be done. The only available solution is to hide the problem under the carpet (portreserve) and ignore cases where it does not work. On the other hand, it'd lower the pressure and the real bug won't be fixed ever (see date and number of original bug report: bug #103401 ). I did not test it, but using systemd socket activation should help here - systemctl enable dovecot.socket, but I did not test it, because rpc port binding race condition is not easily reproducible.
*** This bug has been marked as a duplicate of bug 456401 ***
(In reply to comment #3) > The bug is in glibc: bindresvport() it takes random privileged ports. When > dovecot wanted to start, port was already used by some service. > > One of the most often used services with bad behavior is NFS. ROTFL ... my "rant" was right ... this is the issue having always haunted Red Hat distros. > There is a way to fix that bug #456401, but upstream refused to apply the > fix. > > Semi-working workaround is to use portreserve, but the bug is in different > component. Also it's a bad workaround. ACK, I have been haunted by this issue for many years and am semi-familiar with it ;) The traditional view on such port allocation issues would be to regard them as startup script ordering bugs - I know there are people, who claim there would not be "one single solution" meeting all possibile scenarios' demands. Anyway, as long as RH was using sysvinit, I had always found one, which meet my demands. Also, I had experienced SuSE's "insserv" (which reordered startup script order semi-dynamically) to cater this situation pretty well. > Dovecot uses imap, imaps, pop3, pop3s > and sieve, but there are different services that use these ports. For > example cyrus-imapd. There can be setup where cyrus-imapd serves imap(s) > protocol and dovecot pop3(s) protocol. What ports should dovecot release > before start? Also when both cyrus-imapd and dovecot are running and dovecot > does not run on standard ports. What here? > > For whatever reason we started fixing (adding only semi working ugly > workarounds) in all affected applications instead fixing the one that is > buggy. > > Just recently, I found another case, where this so called solution fails. > When service stops (or dies) port is no longer reserved, so when you try to > start it again, it's not guaranteed that the port is still available. > > It's sad situation, but there is not much to be done. The only available > solution is to hide the problem under the carpet (portreserve) and ignore > cases where it does not work. On the other hand, it'd lower the pressure and > the real bug won't be fixed ever (see date and number of original bug > report: bug #103401 ). I was expecting systemd to save the world ;) > I did not test it, but using systemd socket activation should help here - > systemctl enable dovecot.socket, but I did not test it, because rpc port > binding race condition is not easily reproducible. I'll monitor my machine (I still haven't rebooted and do not know if it was a one-time incident) and keep you posted.
It has happened again: Dec 30 13:19:28 beck dovecot: master: Error: service(pop3-login): listen(*, 995) failed: Address already in use Reopening, because this bug is still present and _is_ affecting users. Closing it as "duplicate" on another "closed" bug is cheating the users.
I did not said it is fixed, so it's no wonder it happened again. If some bug is closed as duplicate and it's not fixed, you should reopen the bug it's duplicate of, not the duplicate itself.
(In reply to comment #7) > If some bug is closed as duplicate and it's not fixed, you should reopen the > bug it's duplicate of, not the duplicate itself. I am reopening the bug I filed, because * I am not sure this bug is a duplicate of bug 456401 at all. * I think bug 456401 should not have been closed. That said, I think this bug is a defect in systemd, which doesn't seem to be able to properly recover from system breakdowns.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.