Bug 1387282

Summary:	RHEL base image should by default run systemd inside the container
Product:	Red Hat Enterprise Linux 7	Reporter:	Daniel Riek <riek>
Component:	rhel-server-container	Assignee:	Frantisek Kluknavsky <fkluknav>
Status:	CLOSED ERRATA	QA Contact:	atomic-bugs <atomic-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.4	CC:	dwalsh, fkluknav, jpazdziora, walters
Target Milestone:	rc	Keywords:	Extras
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-16 17:54:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.