Bug 1285805 - The rhel7.2 docker image sets systemd target to graphical.target
The rhel7.2 docker image sets systemd target to graphical.target
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-server-docker (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Frantisek Kluknavsky
atomic-bugs@redhat.com
: Regression
: 1286665 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-26 09:03 EST by Jan Pazdziora
Modified: 2015-12-08 09:04 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1286787 1286812 (view as bug list)
Environment:
Last Closed: 2015-12-08 09:04:25 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2015-11-26 09:03:56 EST
Description of problem:

With minimal container running systemd, error

Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.

is shown. It seems the default target is now graphical.target, not multi-user.target.

Version-Release number of selected component (if applicable):

registry.access.redhat.com/rhel7.2   latest              6883d5422f4e

How reproducible:

Deterministic.

Steps to Reproduce:
1. docker run --name systemd -t -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e container=docker rhel7.2 /usr/sbin/init
2. In another terminal docker exec -ti systemd systemctl get-default

Actual results:

graphical.target

Expected results:

multi-user.target

Additional info:

docker run --name systemd -t -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e container=docker rhel7.1 /usr/sbin/init provides expected result, thus marking as regression. The dependencies for graphical.target do not seem to be there on the image, plus I'd argue graphical is not the generally expected target for containers.
Comment 1 Jan Pazdziora 2015-11-26 09:18:22 EST
Upon closer examination,

  # docker run --name systemd -t rhel7.2 ls -la /etc/systemd/system/default.target
  systemd
  lrwxrwxrwx. 1 root root 37 Nov 10 09:47 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

shows that the image contains the correct target.

However, systemd during initialization says 
Detected architecture x86-64.

Running with unpopulated /etc.

Welcome to Red Hat Enterprise Linux Server 7.2 (Maipo)!

Set hostname to <d9faac847dca>.
Initializing machine ID from random generator.
Populated /etc with preset unit settings.
Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.

which seems to be caused

                empty_etc = access("/etc/machine-id", F_OK) < 0;
                if (empty_etc)
                        log_info("Running with unpopulated /etc.");

and later

                if (empty_etc) {
                        r = unit_file_preset_all(UNIT_FILE_SYSTEM, false, NULL, UNIT_FILE_PRESET_FULL, false, NULL, 0);

So it looks like the problem is caused by machine-id not being populated.

This is with docker-1.8.2-8.el7.x86_64 in case the problem is in the docker itself.
Comment 2 Jan Pazdziora 2015-11-26 09:22:22 EST
Upgrading to docker-1.9.1-4.el7.x86_64 did not help.
Comment 3 Jan Pazdziora 2015-11-26 09:26:12 EST
Listing the environment variables of the /usr/sbin/init process (as seen on the host) does not show container_uuid to be set.
Comment 4 Frantisek Kluknavsky 2015-11-27 10:31:54 EST
Leaving a valid /etc/machine-id in the image would break a lot of things. We can try to work around this by leaving an empty /etc/machine-id in the container, hopefully breaking not so many things.
Comment 6 Jan Pazdziora 2015-11-27 11:15:06 EST
(In reply to Frantisek Kluknavsky from comment #4)
> Leaving a valid /etc/machine-id in the image would break a lot of things. We
> can try to work around this by leaving an empty /etc/machine-id in the
> container, hopefully breaking not so many things.

I don't think that's the right fix.

IMHO the goal should be for /etc/machine-id to be populated by docker via the container_uuid mechanism which I believe was in place in the past.
Comment 7 Frantisek Kluknavsky 2015-11-30 14:14:49 EST
I guess I can not do anything about it in the image, bug against docker filed: https://bugzilla.redhat.com/show_bug.cgi?id=1286787 (and https://bugzilla.redhat.com/show_bug.cgi?id=1286812)
Comment 8 Frantisek Kluknavsky 2015-12-01 07:35:47 EST
*** Bug 1286665 has been marked as a duplicate of this bug. ***
Comment 10 Martin Jenner 2015-12-07 12:11:51 EST
# docker run --name systemd -t -v /sys/fs/cgroup:/sys/fs/cgroup:ro -e container=docker registry.access.stage.redhat.com/rhel7.2:7.2-38 /usr/sbin/init


In another terminal 

# docker exec -ti systemd systemctl get-default
multi-user.target
Comment 12 errata-xmlrpc 2015-12-08 09:04:25 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-2575.html

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