Red Hat Bugzilla – Bug 426546
Dovecot fails to log in the event that its port(s) are already in use
Last modified: 2008-01-08 16:19:16 EST
Description of problem:
While doing a lab for renewing my RHCE in rh300 I had a problem where dovecot
wouldn't start. No information was put on the screen when I did a 'service
dovecot start'. No logging info was present in any of the obvious logfiles as to
why it failed, it just did. When I ran dovecot from the command line, I
discovered the reason why. It was because the port for imaps was already used
by rpc.rquotad related to the existing RHBZ#187840. This issue is that there
aught to be some sort of logging to syslog to say that the port was already in
use (by default). I recreated this scenario on my centos box using
dovecot-1.0-1.2.rc15.el5 and at least here 'service dovecot start' tells me the
port is already in use. In the lab we were using RHEL 5.1 and it was silent.
Rob Locke, my instructor, pointed out that similar problems were being had by
the RH instructors dealing with portmapped services stealing cups's ip as well.
There is also the issue with portmap assigning a reserved port <1024 AND portmap
gets started before dovecot, giving portmap the opportunity to steal dovecot's
port(s) before dovecot starts. The quick solution to this is to reorder things
so dovecot gets started before portmap. The long-term solution is to blacklist
portmap from handing out ports in /etc/services.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. In another window, nc -l -p 993 (using imaps as example)
2. Configure dovecot for imaps
3. service start dovecot
Lab System RHEL 5.1: "Starting DovecotImap: [failed]" with no log output in
Centos 5 using dovecot-1.0-1.2.rc15.el5 : "Starting Dovecot Imap: Fatal:
listen(995) failed: Address already in use" with no log output in any syslog
that I looked at.
At the very least a syslog entry saying why things failed.
My reporoduction example I used imaps instead of pop3s like I did in my CENTOS 5
This seems to be caused by selinux. Dan, are you aware of this, could you fix
this for 5.2?
Were there entries in the /var/log/audit/audit.log? If you update to U1 does
the problem go away?
I didn't look in /var/log/audit/audit.log. I don't know if there was anything generated there or not. It was
in a classroom setting that I ran into the problem with RHEL 5.1. I'm not sure which exact version was
used. I looked in /var/log/messages and I think /var/log/mail and didn't see anything. Being an old-time
unix guy I'd expect to see something generated in a traditional location, but that's just me. Wish I could
be more help. I *think* that Rob Locke (the instructor) is CC'd on this bug and he might be able to give
the exact version of dovecot that was used.
I didn't see anything in dmesg/logs either, but "setenforce 0" definitely makes
it work and "setenforce 1" makes it stop working.
A lot of fixes went into dovecot policy in U1 and some are in U2, so I believe
this is fixed.
setroubleshoot will put user readable messages in /var/log/messages. It
translates the messages from /var/log/audit/audit.log. Messages in audit.log is
an audit thing, not an SELinux thing, but we are along for the ride.