run postfix in the foreground

[TomasTomecek]

Usually, the containerized services are suppose to run in foreground, no forking. We are using postfix start and a loop which babysits the process, which is kind of odd.

When checking Docker Hub and looking at existing solutions, everyone is using supervisord and using some kind of hacks. The only solution I really liked is this one -- invoking master program directly. Is that a better solution?

[LorbusChris]

Is running it with systemd inside the container an option? (fedora-init-container)
https://fedoraproject.org/wiki/Container:Guidelines#systemd_Containers

It needs the OCI hooks to work, though, which aren't available on all distros.

[phracek]

A long time, I tried to implement it via supervisord but saw, supervisord is not proper solution. But can not find it now.

[LorbusChris]

There also is https://github.com/Yelp/dumb-init
Although I haven't used that personally

[TomasTomecek]

So, systemd inside container is not an option now since we are able to run postfix without systemd. That should be our last option.

supervisord = just no

dumb-init, that doesn't help us much since the tool won't babysit the postfix master process.

My point with this issue is: I want PID 1 in the container to be postfix (or some process from postfix package), that's it.

[LorbusChris]

Systemd is already installed (afaik its in the boltron docker base) and configured with unit files created in the postfix rpm specfile. This is still what the module installs, isn't it?
With systemd, its capabilities such as journal logging and/or even systemd timers could possibly be leveraged.

Support is not too good outside of fedora/rhel, where docker can't invoke the oci-hooks needed for systemd.
For me personally it would be enough if the images ran on fedora and openshift.

However, this disscussion has been held many times before in many places and I guess until the respective fedora committees officially recommend it, this should probably not be the standard setup.

If there were a decision to made to move more towards oci containers on pure runc, where there's better support for this, I would definitely revisit this approach.

My point with this issue is: I want PID 1 in the container to be postfix (or some process from postfix package), that's it.

@TomasTomecek in this case systemd would obviously be PID 1 and systemd doesn't fit in with docker's "one process per container" maxim.

Maybe we can do something like this? In Dockerfile: (edit: this first step might not be necessary)

CMD exec /files/start.sh

and in start.sh:

exec postfix start

edit:
I found this approach here and linked there was this project, which as of v1.13 seems to be included in Docker CE:
https://github.com/krallin/tini
edit2:
Suposing we have all the config in place at container runtime maybe we could define
ENTRYPOINT ["/usr/sbin/postfix"] and
CMD ["start"]

[TomasTomecek]

exec postfix start

won't help since postfix forks and final daemon process is reparented, hence the babysit loop afterwards

postfix seems to be a good candidate for runc/system container. The only thing is that runc doesn't handle networking, so it would probably need to run in host's network namespace.

[phracek]

@LorbusChris Why do you want to have systemd in postfix container? Any specific reason?
Basically, as @TomasTomecek said, as soon as postfix daemon is started it forks several other daemons which cares about sending, posting etc.

Personally, I don't want to have systemd in postfix container. Let's have postfix as PID 1.

[LorbusChris]

@phracek No specific reason, just an idea as I thought journal logging might be helpful. But really any solution that just works (tm) is fine with me.

[LorbusChris]

@TomasTomecek @phracek a change in Kubernetes 1.7 makes PID 1 unavailable for container processes: kubernetes/kubernetes#48937 (comment)

[TomasTomecek]

@LorbusChris thanks for headsup, that could affect us.

[LorbusChris]

@TomasTomecek I just want to link kubernetes/kubernetes#48937 (comment) made by @rhatdan which pretty much sums up why systemd is useful inside containers. The ongoing discussion over there is also related to the PID 1 change. I believe it also indicates there will be a solution to support systemd init-containers.

In your eyes using systemd might not be the cleanest solution, but I can only reiterate that this would give us the ability to gather and extract logs via journald, use systemd-timers within containers, potentially obsoleting cron jobs for that usecase. Also I guess it would make the creation of containerized packages/modules easier, as you'd just follow standard install path in most cases.

I'd like to do something along the lines of this:

FROM modularitycontainers/boltron-preview:latest

ENV container=oci

RUN mkdir -p /run/lock && dnf upgrade -y
RUN dnf install -y --rpm --nodocs findutils && \
    dnf install -y --nodocs postfix freeipa-client && \
    dnf -y clean all

RUN systemctl disable dnf-makecache.timer dnf-makecache.service

COPY build_config.sh /usr/local/lib/build_config.sh
RUN /usr/local/lib/build_config.sh

COPY init.sh /usr/local/sbin/init

VOLUME [ "/var/log/journal", "/var/postfix/certs", "/var/spool/mail" ]

STOPSIGNAL RTMIN+3

# smtp msa ldaps lmtps
EXPOSE 25 587 636 2424

ENTRYPOINT [ "/usr/local/sbin/init" ]

RUN systemctl enable postfix
RUN journalctl -f -p info -u postfix
CMD [ "/sbin/init" ]

[hardware]

http://www.postfix.org/announcements/postfix-3.3.0.html

Container support: Postfix 3.3 will run in the foreground with "postfix start-fg". This requires that Postfix multi-instance support is disable (the default). To collect Postfix syslog information on the container's host, mount the host's /dev/log socket into the container, for example with "docker run -v /dev/log:/dev/log ...other options...", and specify a distinct Postfix syslog_name setting in the container (for example with "postconf syslog_name=the-name-here").

[LorbusChris]

So I guess we're now just waiting for v3.3.0 to be packaged :)
https://bugzilla.redhat.com/show_bug.cgi?id=1548222