Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The postfix MTA stops working if stopped then started with
postfix start
then stopped with
postfix stop
then try to start with
service postfix start
---
The startup will not work because for some reason the
postfix start
command creates a master.pid file under
/var/spool/postfix/pid
as
-rw-------. root root unconfined_u:object_r:var_run_t:s0 master.pid
while the
service postfix start
creates it as:
-rw-------. root root unconfined_u:object_r:postfix_var_run_t:s0 master.pid
This condition is giving messages like:
type=AVC msg=audit(1463156977.010:11428): avc: denied { signal } for pid=19396 comm="postfix-script" scontext=unconfined_u:system_r:postfix_master_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1463157084.605:11435): avc: denied { read write } for pid=19876 comm="cleanup" name="unix.cleanup" dev=xvda1 ino=270120 scontext=unconfined_u:system_r:postfix_cleanup_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file
type=AVC msg=audit(1463157106.254:11436): avc: denied { read write } for pid=19882 comm="showq" name="unix.showq" dev=xvda1 ino=270263 scontext=unconfined_u:system_r:postfix_showq_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file
The problem is with the owner and context of the /var/spool/postfix/pid directory and the files in there.
May 13 17:45:25 elk-a postfix/postfix-script[20376]: starting the Postfix mail system
May 13 17:45:25 elk-a postfix/master[20377]: daemon started -- version 2.6.6, configuration /etc/postfix
May 13 17:45:25 elk-a postfix/cleanup[20381]: fatal: open lock file pid/unix.cleanup: cannot open file: Permission denied
May 13 17:45:26 elk-a postfix/master[20377]: warning: process /usr/libexec/postfix/cleanup pid 20381 exit status 1
May 13 17:45:26 elk-a postfix/master[20377]: warning: /usr/libexec/postfix/cleanup: bad command startup -- throttling
May 13 17:45:26 elk-a postfix/showq[20383]: fatal: open lock file pid/unix.showq: cannot open file: Permission denied
May 13 17:45:27 elk-a postfix/master[20377]: warning: process /usr/libexec/postfix/showq pid 20383 exit status 1
May 13 17:45:27 elk-a postfix/master[20377]: warning: /usr/libexec/postfix/showq: bad command startup -- throttling
ALSO:
restorecon reset /var/spool/postfix/pid context unconfined_u:object_r:postfix_spool_t:s0->unconfined_u:object_r:var_run_t:s0
Looks like by default the pid directory has var_run_t assigned but that disagrees with the policy as evidenced by the restorecon.
Version-Release number of selected component (if applicable):
postfix-2.6.6-6.el6_7.1.x86_64
selinux-policy-targeted-3.7.19-279.el6_7.9.noarch
selinux-policy-3.7.19-279.el6_7.9.noarch
selinux-policy-3.7.19-292.el6.noarch
selinux-policy-targeted-3.7.19-292.el6.noarch
^ this update did not solve it.
How reproducible:
Every time you kill it, even with updated selinux-policy.
Steps to Reproduce:
1. service postfix stop
2. ls -Z /var/spool/postfix/pid/
3. postfix start
4. ls -Z /var/spool/postfix/pid/
5. postfix stop
6. ls -Z /var/spool/postfix/pid/
7. service postfix start
FIX:
8. chcon -t postfix_var_run_t /var/spool/postfix/pid/master.pid
9. ls -Z /var/spool/postfix/pid/
10. service postfix start
Actual results:
Postfix won't start
Expected results:
Postfix starts.
Additional info:
The built-in policy also disagrees on the right context for
/var/spool/postfix/pid/
To reproduce:
1. service postfix stop
2. ls -Zd /var/spool/postfix/pid/ (it is var_run_t)
3. rm -rf /var/spool/postfix/pid/
4. service postfix start
5. ls -Zd /var/spool/postfix/pid/ (it is postfix_spool_t)
6. mailq
Comment 2Jaroslav Škarvada
2016-05-16 08:58:51 UTC
I can confirm the problem. It seems there is nothing setting the context in the postfix code, so it's probably selinux-policy. To workaround the problem we can delete the master.pid after postfix daemon shutdown (but it wouldn't solve the problem if it crashes) or force the PID file context in the init script. But I think it should be fixed preferably in the selinux-policy (if possible), so re-assigning.
Red Hat Enterprise Linux version 6 is entering the Production 2 phase of its
lifetime and this bug doesn't meet the criteria for it, i.e. only high severity
issues will be fixed. Please see
https://access.redhat.com/support/policy/updates/errata/ for further
information.
Feel free to clone this bug to RHEL-7 if it is still a problem for you.
I have a similar problem with fedora 35
root@electron# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2022-04-12 21:26:08 PDT; 8h ago
Process: 9775 ExecStartPre=/usr/sbin/restorecon -R /var/spool/postfix/pid/master.pid (code=exited, status=255/EXCEPTION)
Process: 9776 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
Process: 9778 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
Description of problem: The postfix MTA stops working if stopped then started with postfix start then stopped with postfix stop then try to start with service postfix start --- The startup will not work because for some reason the postfix start command creates a master.pid file under /var/spool/postfix/pid as -rw-------. root root unconfined_u:object_r:var_run_t:s0 master.pid while the service postfix start creates it as: -rw-------. root root unconfined_u:object_r:postfix_var_run_t:s0 master.pid This condition is giving messages like: type=AVC msg=audit(1463156977.010:11428): avc: denied { signal } for pid=19396 comm="postfix-script" scontext=unconfined_u:system_r:postfix_master_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process type=AVC msg=audit(1463157084.605:11435): avc: denied { read write } for pid=19876 comm="cleanup" name="unix.cleanup" dev=xvda1 ino=270120 scontext=unconfined_u:system_r:postfix_cleanup_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file type=AVC msg=audit(1463157106.254:11436): avc: denied { read write } for pid=19882 comm="showq" name="unix.showq" dev=xvda1 ino=270263 scontext=unconfined_u:system_r:postfix_showq_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file The problem is with the owner and context of the /var/spool/postfix/pid directory and the files in there. May 13 17:45:25 elk-a postfix/postfix-script[20376]: starting the Postfix mail system May 13 17:45:25 elk-a postfix/master[20377]: daemon started -- version 2.6.6, configuration /etc/postfix May 13 17:45:25 elk-a postfix/cleanup[20381]: fatal: open lock file pid/unix.cleanup: cannot open file: Permission denied May 13 17:45:26 elk-a postfix/master[20377]: warning: process /usr/libexec/postfix/cleanup pid 20381 exit status 1 May 13 17:45:26 elk-a postfix/master[20377]: warning: /usr/libexec/postfix/cleanup: bad command startup -- throttling May 13 17:45:26 elk-a postfix/showq[20383]: fatal: open lock file pid/unix.showq: cannot open file: Permission denied May 13 17:45:27 elk-a postfix/master[20377]: warning: process /usr/libexec/postfix/showq pid 20383 exit status 1 May 13 17:45:27 elk-a postfix/master[20377]: warning: /usr/libexec/postfix/showq: bad command startup -- throttling ALSO: restorecon reset /var/spool/postfix/pid context unconfined_u:object_r:postfix_spool_t:s0->unconfined_u:object_r:var_run_t:s0 Looks like by default the pid directory has var_run_t assigned but that disagrees with the policy as evidenced by the restorecon. Version-Release number of selected component (if applicable): postfix-2.6.6-6.el6_7.1.x86_64 selinux-policy-targeted-3.7.19-279.el6_7.9.noarch selinux-policy-3.7.19-279.el6_7.9.noarch selinux-policy-3.7.19-292.el6.noarch selinux-policy-targeted-3.7.19-292.el6.noarch ^ this update did not solve it. How reproducible: Every time you kill it, even with updated selinux-policy. Steps to Reproduce: 1. service postfix stop 2. ls -Z /var/spool/postfix/pid/ 3. postfix start 4. ls -Z /var/spool/postfix/pid/ 5. postfix stop 6. ls -Z /var/spool/postfix/pid/ 7. service postfix start FIX: 8. chcon -t postfix_var_run_t /var/spool/postfix/pid/master.pid 9. ls -Z /var/spool/postfix/pid/ 10. service postfix start Actual results: Postfix won't start Expected results: Postfix starts. Additional info: The built-in policy also disagrees on the right context for /var/spool/postfix/pid/ To reproduce: 1. service postfix stop 2. ls -Zd /var/spool/postfix/pid/ (it is var_run_t) 3. rm -rf /var/spool/postfix/pid/ 4. service postfix start 5. ls -Zd /var/spool/postfix/pid/ (it is postfix_spool_t) 6. mailq