If we make this change, we would want to do it in Fedora and Centos also. https://bugzilla.redhat.com/show_bug.cgi?id=1387282
The benefits of making this change are that people new to containers could follow a simple workflow similar to what the do on the OS, where all they need to do is install an rpm service and enable and it is ready to go. # cat Dockerfile FROM rhel7 RUN dnf -y install httpd; systemctl enabled httpd ADD MYAPP / # docker build -t MYAPP . And they are done. Now if they run their container docker run -d MYAPP And their app runs with systemd/journald and httpd with their app runnin inside of it. For users who don't want to use systemd, they would just override the CMD field and their container would work fine. Since the current default is bash, they would need to do this anyways. A couple of things will break, docker run -ti rhel7 Currently runs a shell. With the new change, systemd would start up inside of the contaienr. Users who want a shell would need to execute docker run -ti rhel7 /bin/sh (I always do this anyways, but I guess some people do not) The other big issue is on stopping of containers. docker stop currently defaults to sending SIGTERM to the pid 1 of the container. systemd requires that SIGRTMIN+3 be sent to it to close down properly. If we want to have systemd work by default, we would need to change the default SIGSTOP of the base image. This means any application based on the base image that does not override the SIGSTOP would get SIGRTMIN+3. Most apps will die when they get this signal, but if the App had a signal handler for SIGTERM, the signal handler will not work correctly. Adding SIGSTOP SIGTERM to a Dockerfile would fix the issue, but it will cause unexpected breakage. I don't see an easy solution for this.
