Minor issue, small scope.
Postfix 3.5.8-4.el8 and later has this in the systemd unit:
ExecStartPre=/usr/sbin/restorecon -R /var/spool/postfix/pid/master.pid
This results in the ExecStartPre exiting 255 because the pidfile is created by the ExecStart of the master process, which occurs after all ExecStartPre elements have fired. This should not use the ‘-i’ flag to restorecon as RedHat has suggested because the result would still be a master pidfile that has not had it’s context label explicitly reset. If a restorecon of the master pidfile is appropriate then it must be done after the file is created, not before.
This should not use ExecStartPre, it should use ExecStartPost.
1 Like
Hi,
This exists also in RHEL 8.6, as just installed postfix on both Rocky and RHEL8. So it seems to be an upstream bug that would be needed to be opened here: https://bugzilla.redhat.com/
If a bug report already exists at RHEL for this, then I guess we just need to wait until upstream apply it, and then Rocky will also have it.
2 Likes
I just got curious and looked at my working postfix installation (postfix-3.5.8-4.el8.x86_64).
The installed systemd unit is different:
ExecStartPre=-/usr/sbin/restorecon -R /var/spool/postfix/pid/master.pid
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
Note the leading “-” before the path which means: Ignore the exit code of that command.
Also, your proposal of using ExecStartPost does not make sense at all.
The idea is to handle the following case:
If the pid file happens to already exist AND it has no or wrong selinux label, then postfix would be denied to create/write it. Therefore, restorecon has to be executed before the actual start of postfix. Same goes for the other two ExecStartPre entries.
If it does not exist, that doesn’t matter, because when postfix is creating it, it automatically gets the correct selinux label assigned anyway. (By the selinux kernel system)
That leaves the question: Why is your systemd unit file missing the leading “-”.
2 Likes
I’m on the same page about the systemd unit. My 8 and 9 machines have ExecStartPre=-/... in them. In fact, this is why:
* Thu Feb 17 2022 Jaroslav Škarvada <jskarvad@redhat.com> - 2:3.5.8-4
- Added SELinux workound for systemd service to work after 'postfix start'
Resolves: rhbz#2028015
This is the change log from the latest postfix package. Ensure you have updated your system. See the following for reference: 2028015 – postfix master.pid file not deleted at postfix stop if postfix had been started using postfix start command
2 Likes
If the pidfile happens to exist before postfix starts that’s an error condition with the previous postfix instance, handling that scenario in the way you describe hides evidence of the failure.
Putting it after the launch puts the edge cases forward as the primary use case while generating errors - ignored by systemd - in the logs for all normal startup cases. It’s the very definition of kludge.
Personally I’d rather a previous crash that orphaned a pidfile cause the next launch to fail, and require a reset in systemd. This is my preference with systemd services, and MTAs in particular.
Also, not to put too fine a point on it, but postfix doesn’t read the pidfile’s contents or even index the inode on startup. It reads the pidfile’s parent directory. Tests for file existence, ownership, mode, permbits, size, timestamps, any posix.2 metadata, that’s all done through dirent scans of the patent directory. So the question comes down to what you consider desirable behavior for normal ops vs post-failure scenarios. The convention of automatic recovery after failure is still new to me, it only started gaining traction in the last decade or so. I had been admin’ing UNIX systems professionally for ~12 years when the first GNU linux kernel was drafted so… “old habits die hard”.
1 Like
Upstream reply was yet another instance of, in essence, “we know better than you” and no response on the above three nonsequiturs. So no big deal, the solution by definition has to be a local customization because the boilerplate behavior isn’t appropriate to my specific local use case. (ie, anything that prevents the starting service from placing it’s new pidfile – rather than overwriting or updating an existing one – is an error scenario and thus a block of the start of the service is the desired behavior).
1 Like
If you want to override the default unit file definitions you can do so with systemctl edit postfix. You will get a blank document that you can put new definitions in to override the defaults and they won’t get overwritten when you update postfix. This is generally the best solution if you want to modify the systemd unit from what is provided by the package.
1 Like