A. Schulze:
>
>
> Am 02.04.2018 um 16:10 schrieb Michael Segel:
> > Has anyone successfully implemented a Kubernetes / Docker container setup
> > for Postfix/Dovecot?
>
> it works in my lab environment.
>
> $ docker-compuse up -d postfix
> Creating dockerpostfix_postfix_1 ... done
> $ docker-compose exec postfix /bin/bash
> root@postfix:/# postconf mail_version
> mail_version = 3.3.0
> root@postfix:/# ps afx
> PID TTY STAT TIME COMMAND
> 338 pts/0 Ss 0:00 /bin/bash
> 345 pts/0 R+ 0:00 \_ ps afx
> 1 ? Ss 0:00 /bin/sh /usr/lib/postfix/postfix-script start-fg
> 335 ? Ss 0:00 /usr/lib/postfix/master
> 336 ? S 0:00 \_ pickup -l -t unix -u
> 337 ? S 0:00 \_ qmgr -l -t unix -u
>
> The container's entrypoint is a binary, but at run time PID 1 is /bin/sh.
> That result in hard container shutdown: Docker send SIGTERM to a sh, not to
> usr/lib/postfix/master.
To make the master 'pid 1' one would have to use 'exec
$daemon_directory/master' in the 'postfix-script' file.
However, that fails on every system that I know:
postfix-master[xxx]: fatal: unable to set session and process group ID:
Operation not permitted
The master daemon must run in its own process group and session,
so that after receiving a "postfix stop" signal, the master can
terminate all Postfix daemon processes including processes that
'hang', by sending a signal to the process group.
If the master would not have its own process group and session, it
would kill too many processes. People who ran the master that way
found that Postfix would kill its parent, i.e. the real system init
process, and shutdown the system. That would be unacceptable.
If the master would not kill all Postfix daemon processes including
processes that 'hang', it would be impossible to restart Postfix
without a human manually killing off the hanging process. That would
also be unacceptable.
Wietse
