Bug 1387282 - RHEL base image should by default run systemd inside the container
Summary: RHEL base image should by default run systemd inside the container
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-server-container
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Frantisek Kluknavsky
QA Contact: atomic-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-20 14:14 UTC by Daniel Riek
Modified: 2018-04-16 17:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-16 17:54:28 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Daniel Riek 2016-10-20 14:14:53 UTC
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.

Comment 2 Daniel Walsh 2016-10-20 18:18:12 UTC
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.

Comment 4 Colin Walters 2016-10-21 15:26:28 UTC
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.

Comment 5 Colin Walters 2016-10-21 15:26:45 UTC
Location for public discussion: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/

Comment 6 Daniel Walsh 2016-10-21 15:41:18 UTC
I agree, Lets not ship this until we understand the ramifications of the change.

Comment 7 Frantisek Kluknavsky 2016-10-21 17:17:18 UTC
reverted

Comment 8 Frantisek Kluknavsky 2018-04-16 17:54:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.