Description of problem: Error logged, sm-client.service: Failed to parse PID from file /run/sm-client.pid: Invalid argument Version-Release number of selected component (if applicable): sendmail.x86_64 8.16.1-2.fc33 How reproducible: Every start/restart of sendmail Steps to Reproduce: 1. Start or restart sendmail 2. See journal or syslog 3. Actual results: Error logged, sm-client.service: Failed to parse PID from file /run/sm-client.pid: Invalid argument and sendmail.service: Can't open PID file /run/sendmail.pid (yet?) after start: Operation not permitted Expected results: No errors. Additional info: This was noted in, https://bugzilla.redhat.com/show_bug.cgi?id=1669661 but still not fixed? /run/sm-client.pid & /run/sendmail.pid are the only .pid file in /run to have "2" lines with the first being the PID & second the command line seemingly executed.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Updating - still happens on Fedora 34...
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Changed to FC35 - still happening
8.17.1-1.fc35
This is also happening in EL9: https://bugzilla.redhat.com/show_bug.cgi?id=2128903
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Updating, still happening is FC36 (8.17.1-5.fc36) I don't seem to be able to find the button that used to be here to increase the FC version!?
Updating to FC37... sendmail.x86_64 8.17.1-7.fc37
Updating to 38 & sendmail is now broken due to not being able to create the /var/run/sendmail.pid file! Actually since 8.17.1-8.fc38 ??? type=AVC msg=audit(28/06/23 03:12:33.355:11025) : avc: denied { create } for pid=1154445 comm=sendmail name=sendmail.pid scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=0 type=AVC msg=audit(29/06/23 03:24:25.076:11481) : avc: denied { create } for pid=1386699 comm=sendmail name=sendmail.pid scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=0 type=AVC msg=audit(29/06/23 07:59:15.562:11553) : avc: denied { create } for pid=1459730 comm=sendmail name=sendmail.pid scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=0
Concur that sendmail is now completely broken and this issue needs to be elevated as this breaks system email completely and is now present in Fedora 38. Needs to be assigned and the severity and priority need to be set.
Does it work without selinux?
Doing a setenforce permissive does allow sendmail to start. I did an ausearch -m avc but there was nothing logged.Checking the journalctl -xe came up with the following: Jun 30 07:44:06 douglas systemd[1]: sendmail.service: Can't open PID file /run/sendmail.pid (yet?) after start: No such file or directory Jun 30 07:44:06 douglas audit[28514]: AVC avc: denied { create } for pid=28514 comm="sendmail" name="sendmail.pid" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 Jun 30 07:44:06 douglas audit[28514]: AVC avc: denied { write open } for pid=28514 comm="sendmail" path="/run/sendmail.pid" dev="tmpfs" ino=3261 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 Jun 30 07:44:06 douglas audit[28514]: AVC avc: denied { getattr } for pid=28514 comm="sendmail" path="/run/sendmail.pid" dev="tmpfs" ino=3261 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 Jun 30 07:44:06 douglas audit[28514]: AVC avc: denied { lock } for pid=28514 comm="sendmail" path="/run/sendmail.pid" dev="tmpfs" ino=3261 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1
Could you please try: # restorecon /run/sendmail.pid or removing the PID: # rm -f /run/sendmail.pid
The PID file is removed when the sendmail service is stopped so the above restorecon command fails.
I concur with all David's comments above. Is it also still broken in Red Hat Enterprise Linux 9? (https://bugzilla.redhat.com/show_bug.cgi?id=2128903) If so it seems to be something that really does need urgent attention.
It appears to be now fixed in Fedora 38 as of updates for July 6th where there was kernel update so the systems were all rebooted and sendmail started at boot time. I checked the journal and found no squawks for the sendmail. I checked the dnf logs for the previous four days and found no update that would fix this issue.
Agreed, the latest kernel (6.3.11-200.fc38.x86_64) boot & no sendmail error & it started, ran & delivered mail! Lets hope the same is true for the next kernel ;-)