[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 15-Jan-16 18:14 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 15-Jan-16 18:24 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 13-Jan-16 23:21 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 11-Jan-16 17:49 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 11-Jan-16 17:51 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 11-Jan-16 19:35 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 11-Jan-16 19:47 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 05-Jan-16 22:20 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 29-Dec-15 23:14 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 29-Dec-15 23:10 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 28-Dec-15 23:00 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 28-Dec-15 21:04 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 28-Dec-15 21:13 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 28-Dec-15 21:30 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 24-Dec-15 15:13 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 24-Dec-15 15:38 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 23-Dec-15 20:41 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 08-Dec-15 16:30 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 03-Dec-15 22:34 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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: 13-Nov-15 16:28 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
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 ModifiedUsername FieldChange == 12-Nov-15 15:48 GorbashNew Issue == ___ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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:57 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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 16:45 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
[Dbmail-dev] [DBMail 0001076]: DBMail services dbmail-pop3d OR dbmail-lmtpd remain inactive after start and enable, erratic start on one or the other
A NOTE has been added to this issue. == 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 16:29 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? == -- (0003707) thelounge (reporter) - 12-Nov-15 15:57 http://www.dbmail.org/mantis/view.php?id=1076#c3707 -- besides that 3.1.16 is missing a important bugfix from 3.1.17 that sounds more like wrong systemd-units effective group shall be [nogroup]", but RHEL 7 uses nobody/nobody instead of nobody/nogroup. i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" effective_user= dbmail effective_group = dbmail the units below are working here from Fedora 15 to Fedora 23 ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-pop3d.service [Unit] Description=DBMail POP3 Server After=network.service systemd-networkd.service network-online.target mysqld.service Before=dovecot.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-pop3d -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr [Install] WantedBy=multi-user.target ___ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=network.service systemd-networkd.service network-online.target mysqld.service [Service] Type=simple ExecStart=/usr/sbin/dbmail-lmtpd -D Environment="LANG=en_GB.UTF-8" Restart=always RestartSec=1 TimeoutStopSec=5 LimitNOFILE=5 PrivateTmp=yes PrivateDevices=yes CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK
