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): How reproducible: Easily. Steps to Reproduce: 1. In another window, nc -l -p 993 (using imaps as example) 2. Configure dovecot for imaps 3. service start dovecot Actual results: Lab System RHEL 5.1: "Starting DovecotImap: [failed]" with no log output in syslog 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. Expected results: At the very least a syslog entry saying why things failed. Additional info:
My reporoduction example I used imaps instead of pop3s like I did in my CENTOS 5 test. Whoops...
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.