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-privileged-container/ ==== 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 _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
