Older Postfix versions < 3.4.7-2 shipped with the following line in the init script, to determine whether the process is running or not:

dir=$(ls -l /proc/$pid/exe 2>/dev/null | sed 's/.* -> //; s/\/[^\/]*$//')

That required the Docker container SYS_PTRACE capability.

Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941293

Documentation preview for this PR is ready! 🎉

Built with commit: 66f7cf7

@casperklein Oh awesome thank you so much for sharing that! 😁

Good to know this is safe to go ahead with then :)

@casperklein would this also mean that the wrapper scripts aren't likely required anymore? At least for Postfix?

Or do you know if the concerns about losing PID remain valid for using postfix reload in check-for-changes.sh instead of supervisorctl restart postfix?

The wrapper script is (still) needed, because:

However, there should be no problem when issuing service postfix reload etc.

Not sure if I understood your question correctly, let me know if not 😉

The wrapper script is (still) needed, because:

docker-mailserver/target/scripts/wrapper/postfix-wrapper.sh

Lines 3 to 8 in 851ec8c

	# You cannot start postfix in some foreground mode and
	# it's more or less important that docker doesn't kill
	# postfix and its chilren if you stop the container.
	#
	# Use this script with supervisord and it will take
	# care about starting and stopping postfix correctly.

What about https://serverfault.com/a/916072?

I didn't know that. That might be worth investigating/testing. Not sure, if the things sekretts mentions in his comment could cause problems in our setup.

What about https://serverfault.com/a/916072?

I'm not sure what benefit there is from starting Postfix in foreground mode for a multi-service/process container? Isn't this the difference between docker-compose up and docker-compose up -d? Or is this different because supervisord is handling it, and foreground mode would be preferable there?

Postfix 3.3 (Feb 2018) and Postfix 3.4 (March 2019) mentioned in the link at least does mean those were not available originally in Oct 2017 when the wrapper workaround was added. So I suppose it could be worth looking into.

Not sure, if the things sekretts mentions in his comment could cause problems in our setup.

Someone running Podman Rootless had some odd permission issues occur, not sure why though:

#2630 (comment)

It affected /var/spool/postfix/private rather than /var/spool/postfix/etc, although this was with our current image not the suggested alternative way to start Postfix.

However, there should be no problem when issuing service postfix reload etc.

This was apparently an issue cited around the same time, some concern about losing a PID. The maintainer at the time did not clarify the concern that well.

I'm not sure what benefit there is from starting Postfix in foreground mode

No benefit, but a requirement for supervisord. Because postfix did not support foreground mode in the past, the wrapper script was needed.

1. supervisord expects the command to be running in the foreground, so that signals like SIGTERM can be passed through. command=service postfix start for example is a one-shot (it immediately exits after execution, so no signals can be passed).
2. More important, if the command exits, supervisord "thinks" the process is gone and trys to restart, since we set autorestart=true in target/supervisor/conf.d/supervisor-app.conf. This leads to an endless restart loop (postfix is running, but supervisord falsely think its gone and trys to restart it)