The following issue has been SUBMITTED. ====================================================================== http://www.dbmail.org/mantis/view.php?id=1076 ====================================================================== Reported By: Gorbash Assigned To: ====================================================================== Project: DBMail Issue ID: 1076 Category: POP3 daemon Reproducibility: have not tried Severity: block Priority: normal Status: new target: ====================================================================== Date Submitted: 12-Nov-15 15:48 CET Last Modified: 12-Nov-15 15:48 CET ====================================================================== Summary: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other Description: As part of testing an updated version of DBMail (a year or so newer than the one we have in production), we set up a test RHEL server and pulled version 3.1.16 from an existing channel. Unfortunately, after making sure that the channel installed all the required libraries and files, and updating the configuration URI to our test database, we've hit a snag.
The two DBMail services we use are dbmail-lmtpd and dbmail-pop3d. Every time we try to start both services, one of the following things will happen: 1. Both services stick at loaded/enabled but inactive, no PID files show up, and logging in dbmail.err for each service stops at "effective group shall be [nobody]" 2. One service will become active, but the other will stick at loaded/enabled but inactive; the active service will have a PID file, but not the inactive one, and logging in dbmail.err for the inactive service stops at "effective group shall be [nobody]" while the other passes that step and completes normally. When this happens, its usually (but not always) the first service tried that becomes active. Normally, the default config would produce "effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. Nevertheless, I tried changing it back to nobody/nogroup in dbmail.conf, and got a result matching http://www.dbmail.org/mantis/view.php?id=2, above. We've also tried using a specific account, and setting the referenced files to match that account, but in that case, neither process will become active and no PID file is generated. The only other error message I've seen is a "can't drop permissions" message from the active service in /var/log/dbmail, before the messages from the inactive service start. We haven't had this problem on our previous test or production servers, so I think it might have something to do with RHEL 7. I'm hoping that's not the case, however, as RHEL 7 dramatically improved the installation of other services we've added onto this server. Any ideas on what this might be stemming from? ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 12-Nov-15 15:48 Gorbash New Issue ====================================================================== _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev