Description of problem: sendmail does start automatically but leaves in logs these: -- Subject: Unit sendmail.service has begun with start-up -- Unit sendmail.service has begun starting up. Jan 25 09:55:36 yyyy systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. Jan 25 09:55:35 yyyy sendmail[1060]: starting daemon (8.14.7): SMTP+queueing@01:00:00 (Yes, reversed timestamps are straigth from journalctl output.) Version-Release number of selected component (if applicable): sendmail-8.14.7-5.fc21 How reproducible: always Steps to Reproduce: 1. run 'systemctl restart sendmail.service' and read this "pid line" from 'systemctl -l status sendmail.service' Additional info: /run/sendmail.pid after a restart has a content like this: 1326 /usr/sbin/sendmail -bd -q1h Is it possible that whatever tries to read sendmail.pid runs an 'smmsp' user while /run/sendmail.pid has "-rw------- 1 root smmsp" access permits? On this test installation selinux is turned off so, at least at this stage, it is not involved in blocking that read.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
This bug appears on Fedora 23 too: systemd[1]: sendmail.service: PID file /run/sendmail.pid not readable (yet?) after start: No such file or directory -rw-------. 1 root smmsp 34 2. Mär 00:15 /run/sendmail.pid But I cannot reproduce it on my (last) Fedora 22 system now.
From [url]https://www.freedesktop.org/software/systemd/man/systemd.service.html[/url] "Please set PIDFile= accordingly. Note that the daemon should write that file before finishing with its initialization. Otherwise, systemd might try to read the file before it exists." So it looks like sendmail creates pid file before exit ... (makes sense since sendmail have 2 processes) , editing /usr/lib/systemd/system/sendmail.service and comment out PIDFile entry [1], solves the problem, I don't known if it's worth report it, but seems still works correctly and don't report any warning. [1] #PIDFile=/run/sendmail.pid
(In reply to Sergio Monteiro Basto from comment #3) > From > [url]https://www.freedesktop.org/software/systemd/man/systemd.service.html[/ > url] > > "Please set PIDFile= accordingly. Note that the daemon should write > that file before finishing with its initialization. Otherwise, systemd > might try to read the file before it exists." > We tried to get patches upstream, but it is not trivial change that may lead to backward incompatibility. > So it looks like sendmail creates pid file before exit ... (makes sense > since sendmail have 2 processes) , editing > /usr/lib/systemd/system/sendmail.service and comment out PIDFile entry > [1], solves the problem, I don't known if it's worth report it, but > seems still works correctly and don't report any warning. > > [1] > #PIDFile=/run/sendmail.pid IMHO unsetting PIDFile would lead to PID guessing: GuessMainPID= Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile= is unset because for the other types or with an explicitly configured PID file, the main PID is always known. The guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined, failure detection and automatic restarting of a service will not work reliably. Defaults to yes. Is it causing any other trouble except the diagnostic message?
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.