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=50000 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=50000 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 ---------------------------------------------------------------------- (0003708) Gorbash (reporter) - 12-Nov-15 16:29 http://www.dbmail.org/mantis/view.php?id=1076#c3708 ---------------------------------------------------------------------- --i wonder really why because normally you have a user "dbmail" and a group "dbmail" instead abuse "Nobody" Default on the configs is nobody/nogroup, and that's what our prod servers (which are *not* RHEL 7) use. We also gave an alternate user (user exim / group exim) a shot earlier, but I can give user / group dbmail a shot if you think it'll work. Meantime, since this install of DBmail was provided by a RedHat channel, we've been using the systemd files that came with the RPM (listed below). I'm a little hesitant about messing with them too much since they did come from the channel, so they should have worked as-is. # cat dbmail-pop3d.service [Unit] Description=DBMail pop3 Server After=syslog.target network.target mysqld.service postgresql.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/dbmail-pop3d ExecStart=/usr/sbin/dbmail-pop3d [Install] WantedBy=multi-user.target # cat dbmail-lmtpd.service [Unit] Description=DBMail LMTP Server After=syslog.target network.target mysqld.service postgresql.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/dbmail-lmtpd ExecStart=/usr/sbin/dbmail-lmtpd [Install] WantedBy=multi-user.target ---------------------------------------------------------------------- (0003709) thelounge (reporter) - 12-Nov-15 16:45 http://www.dbmail.org/mantis/view.php?id=1076#c3709 ---------------------------------------------------------------------- i doubt that dbmail 3.1.16 is from the default channel since it are systemd-units it RHEL7 there is no dbmail at all except EPEL repo epel repo has 3.2.3 and there was never 3.1.16 https://koji.fedoraproject.org/koji/packageinfo?packageID=1572 the epel-package clearly creates a dbmail user ____________________________________ %pre getent group %{name} >/dev/null || groupadd -r %{name} getent passwd %{name} >/dev/null || \ useradd -r -M -g %{name} -d / -s /sbin/nologin \ -c "DBMail Daemon" %{name} exit 0 ____________________________________ that part of the shipped "dbmail.conf" from the package is simply a bug when due instal there is a user dbmail created effective_user = nobody effective_group = nogroup ____________________________________ that sed-snippet from the rpm-spec just don't work as intended because it's uppercase and in the meantime the values in the sample config from the tarball are lowercase, that said about the quality of the package, there is a reason why i build my own rpm for the last 6 years # make a couple of changes to the default dbmail.conf file: # 1. default driver/authdriver sqlite/sql # 2. effective uid/gid to dbmail/dbmail sed -i 's/\(^driver\W*=\)\(\W*$\)/\1 sqlite/' dbmail.conf sed -i -e 's,\(^db\W*=\)\(.*$\),\1 %{_localstatedir}/lib/dbmail/dbmail.db,' \ -e 's/\(^authdriver\W*=\)\(\W*$\)/\1 sql/' \ -e 's/\(^EFFECTIVE_USER\W*=\)\(.*$\)/\1 dbmail/' \ -e 's/\(^EFFECTIVE_GROUP\W*=\)\(.*$\)/\1 dbmail/' dbmail.conf ---------------------------------------------------------------------- (0003710) Gorbash (reporter) - 13-Nov-15 16:28 http://www.dbmail.org/mantis/view.php?id=1076#c3710 ---------------------------------------------------------------------- You're correct, we're on 3.2.3. I didn't see it as an option on dropdown, so I picked the closest version in the dropdown (which would have been 3.1.17; apparently, I missed and hit 3.1.16 instead). We're running off of a separate MySQL server as a database instead of SQLite. Do I still need to change the default driver in that case? I'm not really seeing any difference after changing the effective user and group in dbmail.config to dbmail/dbmail. Do the associated files also have to be assigned to dbmail/dbmail? ---------------------------------------------------------------------- (0003711) Gorbash (reporter) - 27-Nov-15 22:14 http://www.dbmail.org/mantis/view.php?id=1076#c3711 ---------------------------------------------------------------------- We've switched to dbmail/dbmail, but neither dbmail-pop3d nor dbmail-lmtpd are starting after the change. Are you sure we should be changing the default driver? We're using a MySQL server. ---------------------------------------------------------------------- (0003712) Gorbash (reporter) - 03-Dec-15 22:34 http://www.dbmail.org/mantis/view.php?id=1076#c3712 ---------------------------------------------------------------------- Issue persists, even with the listed changes to our dbmail.conf file, and all files owned by dbmail / dbmail. ---------------------------------------------------------------------- (0003713) Gorbash (reporter) - 08-Dec-15 16:30 http://www.dbmail.org/mantis/view.php?id=1076#c3713 ---------------------------------------------------------------------- New dbmail.err logs are as follows: Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Info:[debug] configure_debug(+79): [POP] syslog [31 -> 31] stderr [31 -> 511] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1015): max_db_connections [10] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[config] config_get_timeout(+445): timeout [300] seconds Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[config] config_get_timeout(+456): login_timeout [60] seconds Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1024): no value for SOCKET in config file Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1026): socket [] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1047): binding to PORT [110] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1076): binding to IP [0.0.0.0] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1082): no value for BACKLOG in config file. Using default value [128] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1086): POP backlog [128] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1093): not resolving client IP Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1102): Disabling POP-before-SMTP Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1109): Disabling POP Authentication logging Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1119): effective user shall be [dbmail] Dec 08 09:26:53 oexdev1 dbmail-pop3d[56241]: [0x7fcf2fd6b000] Debug:[server] server_config_load(+1128): effective group shall be [dbmail] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Info:[debug] configure_debug(+79): [LMTP] syslog [31 -> 31] stderr [31 -> 511] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1015): max_db_connections [10] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[config] config_get_timeout(+445): timeout [300] seconds Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[config] config_get_timeout(+456): login_timeout [60] seconds Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1024): no value for SOCKET in config file Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1026): socket [] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1047): binding to PORT [24] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1076): binding to IP [0.0.0.0] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1082): no value for BACKLOG in config file. Using default value [128] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1086): LMTP backlog [128] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1093): not resolving client IP Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1100): no value for LMTP_BEFORE_SMTP in config file Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1102): Disabling LMTP-before-SMTP Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1109): Disabling LMTP Authentication logging Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1119): effective user shall be [dbmail] Dec 08 09:26:57 oexdev1 dbmail-lmtpd[56258]: [0x7fe25269f000] Debug:[server] server_config_load(+1128): effective group shall be [dbmail] It looks like it cuts off at the same spot as with nobody/nobody. Could it be a problem with the dbmail account that should have been generated with it? ---------------------------------------------------------------------- (0003716) Gorbash (reporter) - 23-Dec-15 20:41 http://www.dbmail.org/mantis/view.php?id=1076#c3716 ---------------------------------------------------------------------- We have now tried reinstalling this DBMail setup and setting effective group / user to dbmail, and we're still running into the exact same issue, with the logs cutting off at that point. You mentioned earlier setting our authdriver to SQL and our driver to sqlite. According to the config we have, the driver field is deprecated. I can confirm our authdriver field is set to SQL; should I reactivate the driver field and change it to sqlite? Otherwise, I'm running out of ideas on what else we can try with this. Should I just try building a new RPM based on the example you listed at the beginning? ---------------------------------------------------------------------- (0003717) Gorbash (reporter) - 24-Dec-15 15:13 http://www.dbmail.org/mantis/view.php?id=1076#c3717 ---------------------------------------------------------------------- I think I've spotted part of the problem. You mention a dbmail.db in the line here: "sed -i -e 's,\(^db\W*=\)\(.*$\),\1 %{_localstatedir}/lib/dbmail/dbmail.db,' \" Not only do we not have a directory named dbmail in lib (though we have one in lib64), we can't find a dbmail.db file anywhere within our structure. The install should have created that file, correct? Could that be why we can't start? ---------------------------------------------------------------------- (0003718) thelounge (reporter) - 24-Dec-15 15:38 http://www.dbmail.org/mantis/view.php?id=1076#c3718 ---------------------------------------------------------------------- there is no "dbmail.db" when you are using mysql/postgreqsl as storage and {_localstatedir} has nothing to do with lib64 - {_localstatedir} translates to /var and so it would be /var/lib/dbmail/ the tyical runtime-data directory like /var/lib/samba, /var/lib/hdcp, /var/lib/mysql and son on which is by definition arch-agnostic ---------------------------------------------------------------------- (0003719) Gorbash (reporter) - 28-Dec-15 21:04 http://www.dbmail.org/mantis/view.php?id=1076#c3719 ---------------------------------------------------------------------- If there's no dbmail.db, what is that line referencing? I would assume its referring to the mysql db, but I wouldn't think the user the DB is running would affect whether or not DBMail activates over here. If that's the case, then changing to effective user DBMail and effective group DBMail should have started this. Do you have any other ideas about what might be preventing either process from starting? Issue History Date Modified Username Field Change ====================================================================== 12-Nov-15 15:48 Gorbash New Issue 12-Nov-15 15:52 Gorbash Issue Monitored: Gorbash 12-Nov-15 15:57 thelounge Note Added: 0003707 12-Nov-15 16:29 Gorbash Note Added: 0003708 12-Nov-15 16:45 thelounge Note Added: 0003709 13-Nov-15 16:28 Gorbash Note Added: 0003710 27-Nov-15 22:14 Gorbash Note Added: 0003711 03-Dec-15 22:34 Gorbash Note Added: 0003712 08-Dec-15 16:30 Gorbash Note Added: 0003713 23-Dec-15 20:41 Gorbash Note Added: 0003716 24-Dec-15 15:13 Gorbash Note Added: 0003717 24-Dec-15 15:38 thelounge Note Added: 0003718 28-Dec-15 21:04 Gorbash Note Added: 0003719 ====================================================================== _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev