Hide Forgot
The RHEL base image CMD and Labels should be set up by default to run systemd inside the container following the instructions in : http://developers.redhat.com/blog/2016/09/13/running-systemd-in-a-non-privileged-container/ This would allow layered images to behave by default as a RHEL admin would expect from an existing system. At the same time, it would not affect any existing layered builds that oververite CMD.
I think we could do this, except for one big issue. Currently in order to get systemd to stop correctly inside of a container, you need to send a different stop signal.SIGRTMIN+3, where normal containers are stopped using SIGTERM. We could change the json file of the base image to use the SIGRTMIN+3 stop signal by default, but then any containers based off of it, would need to use STOPSIGNAL SIGTRM Sending SIGRTMIN+3 to a process seems to kill it fine, but I think we would need to worry about this causing problems. Setting the CMD=/bin/init should be fine, because most people who build non systemd containers would override the CMD field.
I don't think we should be making fundamental changes like this *first* in RHEL. These types of things should go upstream (Fedora/CentOS) first, and specifically in this case I really think it warrants some public discussion. It's definitely going to break some of my workflows; I often do `docker run --rm -ti rhel7` type things for a quick shell. Obviously, appending /bin/bash there isn't hard. But it's also different from the Fedora/CentOS base images. I'm very sure I'm not the only person who will find this confusing.
Location for public discussion: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/
I agree, Lets not ship this until we understand the ramifications of the change.
reverted
rhel-server-docker will continue to run bash by default. A different image, rhel7-init-docker, built on top of rhel-server-docker, will run systemd by default.