Bug 1267031
Summary: | dbmail services daemons fail to start (systemd) on CentOS 7 (v7.1) | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Mauro Mozzarelli <mm13> |
Component: | dbmail | Assignee: | Bernard Johnson <bjohnson> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | bjohnson, lieb, tdawson |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-04-27 19:52:16 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Mauro Mozzarelli
2015-09-28 21:02:59 UTC
Please find below a working systemd file for dbmail-imapd. The same can be edited and applied to pop3d, lmtpd and timsieved. /usr/lib/systemd/system/dbmail-imapd.service: [Unit] Description=DBMail IMAP Server After=syslog.target network.target mariadb.service postgresql.service [Service] Type=forking EnvironmentFile=-/etc/sysconfig/dbmail-imapd PIDFile=/var/run/dbmail/dbmail-imapd.pid ExecStartPre=/usr/bin/install -d -m 0777 -o nobody -g nobody /var/run/dbmail ExecStart=/usr/sbin/dbmail-imapd -p /var/run/dbmail/dbmail-imapd.pid ExecStop=/usr/bin/kill -TERM $MAINPID ExecReload=/usr/bin/kill -HUP $MAINPID RemainAfterExit=yes SuccessExitStatus=1 [Install] WantedBy=multi-user.target I have tracked this down further because I have the same problem on F23. I have also looked at the solution in comment #1 and it too has the "daemon-reload" problem. I don't think systemd is at fault here because the dbmail code does some strange things on its way to spawning the working daemon proc. Other legacy daemons do work, probably because they let the spawned child do most of the initialization. My F20 based service had the same problem of failing to start although it would work sometimes rather than the f23 behavior of not at all... What works is to move from "forked" to "simple" daemon. Fortunately, dbmail supports this. Here is my override file for imapd: # cat /etc/systemd/system/dbmail-imapd.service.d/override.conf [Unit] After=nss-lookup.target [Service] Type=simple ExecStart= ExecStart=/usr/sbin/dbmail-imapd -D As with comment #1, apply this to all the other daemons. By going to "simple" we let systemd manage the cgroup itself and eliminate the pid file (always was a) hack. The '-D' flag bypasses the daemonizing bit, saving a fork+exit in startup. However, while fixing the "daemon-reload" problem, the daemons still did not start at boot time even though I could reliably start them later with systemctl. The second item is the "After". My dbmail instance is isolated in a VM and the database (postgresql) is on a bare-metal host. Without waiting for "nss-lookup.target", each of the daemons fail because they too eagerly and silently bail during initialization because they are racing not only the basic network but the nss services etc. because (in my case) the route table has not settled down. This target waits on DNS connectivity. BTW, I found this by cranking up the file debugging to "511" but even that was vague. I ended up using strace which showed that the DB connect was failing with an ENOROUTE error when trying to connect to my DNS indicating that network.target is too weak a dependency. Note that stuffing the server address into /etc/host just postpones until the DB socket is connected... I recommend that the package service files change to use "simple" and "-D". I haven't straced the "forked" daemons but I suspect that dbmail is quietly exiting due to unhappy initialization code in the parent that really should be done by the spawned child. I also suggest changing the "After" so that partitioned services like mine would work. network.target is too weak and nss-lookup.target would work just fine for local (UNIX socket) database connections. dbmail no longer in centos7 I meant to say it is no longer in epel7. |