jasonbrooks added a new comment to an issue you are following:
``
I made some edits (I made them in a google doc and sent you the link if you want that):
=== systemd-Based Containers ===
A systemd-based container runs systemd(/usr/bin/init) by default as its entrypoint. One or
more services are configured using unit files, the say way they would be on a physical
system or a virtual machine.
systemd based containers have some advantages over running a service directly as the
entrypoint (pid 1):
Support for multi service containers.
Support for unit file mechanism for starting the container.
Ability to reap zombie processes.
Population of /tmp with content needed to be run by a service
Proper handling of syslog messages
Proper handling of journalctl messages
==== Issues with systemd based containers ====
STDOUT/STDERR of the container does not come back though the container runtime logging
system. systemd adds some requirements on the mechanism that containers are run:
systemd requires that a tmpfs be mounted at /run.
systemd requires that /sys/fs/cgroup be available inside of the container
systemd requires that the signal to stop the container is SIGRTMIN+3
systemd likes if /tmp is a tmpfs.
For more information on systemd in a container read this link.
https://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-pr...
==== LABELS ====
Run/Usage: Installing the oci-systemd-hook and oci-register-machine packages alongside the
docker packaged shipped in Fedora takes care of most of the setup for running a systemd
container. However, in order to provide compatibility with other container hosts,
systemd-based containers should include a Run or Usage label that directs users to include
the "--tmpfs /run", "--tmpfs /tmp", and "-v
/sys/fs/cgroup:/sys/fs/cgroup" that systemd requires to run.
For example:
<pre>
LABEL Usage="docker run -d -P --tmpfs /run --tmpfs /tmp -v
/sys/fs/cgroup:/sys/fs/cgroup SYSTEMDIMAGE"
</pre>
Note: On a container host without oci-systemd-hook and oci-register-machine, log files
will not appear on the host, since there’ll be no way to make the logs available outside
of the container.
==== CMD/ENTRYPOINT ====
systemd-based containers must include "/sbin/init" as an ENTRYPOINT or CMD,
which will start systemd inside the container at run time. systemd will start up and
manage services enabled with the Dockerfile using the standard "systemctl enable
foo" commands in RUN statements.
For example:
<pre>
FROM fedora:25
ENV container=oci
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
STOPSIGNAL SIGRTMIN+3
EXPOSE 80
CMD [ "/sbin/init" ]
</pre>
Fedora now also provides a base-init container called fedora-init. This image is setup to
running systemd containers by default. This means your Dockerfile could be as simple as
<pre>
FROM fedora-init:25
RUN dnf -y install httpd; dnf clean all; systemctl enable httpd
EXPOSE 80
</pre>
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/233