[atomic-devel] We have a bugzilla requesting that we change the default CMD to systemd for base images in RHEL

[Daniel J Walsh <dwalsh redhat com>]

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.