Bug 1201663

Summary: The default multi-user.target configured in rhel7.1 images runs /usr/bin/rhsmcertd
Product: Red Hat Enterprise Linux 7 Reporter: Jan Pazdziora (Red Hat) <jpazdziora>
Component: rhel-server-containerAssignee: Václav Pavlín <vpavlin>
Status: CLOSED WONTFIX QA Contact: atomic-bugs <atomic-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: dwalsh, fedoraproject, jpazdziora, ovasik, vpavlin
Target Milestone: rcKeywords: Extras
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1299908 (view as bug list) Environment:
Last Closed: 2020-12-15 07:33:39 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:
Bug Depends On: 1094932, 1209382, 1382308    
Bug Blocks:    

Description Jan Pazdziora (Red Hat) 2015-03-13 08:46:27 UTC
Description of problem:

Create minimal image which runs systemd(-container) based on rhel7.1, using Dockerfile

   FROM rhel7.1
   RUN yum install -y /usr/bin/ps
   ENV container docker
   CMD [ "/usr/sbin/init" ]

Run a container and inspect running processes -- /usr/bin/rhsmcertd will be there. It's because

   rhsmcertd.service

service is enabled in

   /etc/systemd/system/multi-user.target.wants/rhsmcertd.service

The man rhsmcertd(1) says

        Periodically scans and updates the entitlement certificates on
        a registered system.

but in a container, entitlement certificates are inherited from the
host. It seems this service should be removed from the target.

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

Image rhel7.1
docker-1.5.0-16.el7.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have Dockerfile as shown above.
2. Build, run a container.
3. Check the processes running in the container using

   docker exec <the-container-id> ps axuwwf

Actual results:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        70  0.0  0.0  19760  1132 ?        R    04:39   0:00 ps axuwwf
root         1  0.5  0.0  44752  2800 ?        Ss   04:39   0:00 /usr/sbin/init
root        63  0.0  0.0  32144  2640 ?        Ss   04:39   0:00 /usr/lib/systemd/systemd-journald
root        68  0.0  0.0   9740   668 ?        Ss   04:39   0:00 /usr/bin/rhsmcertd
root        69  0.0  0.0   6424   840 ?        Ss   04:39   0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600


Expected results:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        70  0.0  0.0  19760  1132 ?        R    04:39   0:00 ps axuwwf
root         1  0.5  0.0  44752  2800 ?        Ss   04:39   0:00 /usr/sbin/init
root        63  0.0  0.0  32144  2640 ?        Ss   04:39   0:00 /usr/lib/systemd/systemd-journald
root        69  0.0  0.0   6424   840 ?        Ss   04:39   0:00 /sbin/agetty --noclear --keep-baud console 115200 38400 9600

Additional info:

Comment 2 Jan Pazdziora (Red Hat) 2015-03-13 08:51:35 UTC
Adding

   RUN rm -f /etc/systemd/system/multi-user.target.wants/rhsmcertd.service

to my Dockerfile helps but I believe it should be in the base image, unless there is a strong reason to run rhsmcertd by default.

Comment 3 Václav Pavlín 2015-03-13 15:42:56 UTC
Can we change this in systemd-container? I would like to keep kickstart files clean from init process modifications.

Comment 4 Lukáš Nykrýn 2015-03-13 17:36:56 UTC
How can I change this is systemd package? That service is enabled after instalation and it seems not to use presets.

Comment 5 Frantisek Kluknavsky 2016-01-19 14:24:08 UTC
Let's rm the symlink for now but leave this bug open waiting for a proper solution. https://bugzilla.redhat.com/show_bug.cgi?id=1299908

Comment 6 Daniel Walsh 2016-10-18 15:48:08 UTC
Any movement on this bug?

Comment 7 Jan Pazdziora (Red Hat) 2017-10-18 08:20:44 UTC
It looks like bug 1299908 mentioned waiting for bug 1209382 which was marked as duplicate of bug 1271839 which was resolved in RHEL 7.4.

So the question is, can the "workaround" introduced in bug 1299908 be reverted with proper preset-based approach now available?

Comment 8 Frantisek Kluknavsky 2018-04-17 13:48:14 UTC
As far as I know, we do not have a packaged container-specific preset file. We almost had one two years ago, but the idea was intentionally canceled without explanation. See bug 1382308.
We can try to get a new rpm into rhel7 but that requires an unlikely agreement of a lot of people. Do you have a better suggestion?

Comment 9 Jan Pazdziora (Red Hat) 2018-04-17 14:04:57 UTC
Can you verify that the problem is still present with current images?

IIRC, you can make things conditional in the .service, not to run it in containers.

The systemd environment in containers should have sane defaults, so minimize the amount of work that needs to be done to the image by its users.

Comment 10 James Cassell 2020-06-19 07:41:49 UTC
Would be properly solved for all cases by adding to the rhsmcertd.service file:

ConditionPathIsDirectoryNotEmpty=!/etc/pki/entitlement-host

Problem is that `ConditionPathIsDirectoryNotEmpty` is currently broken: https://github.com/systemd/systemd/issues/16220

Comment 11 James Cassell 2020-06-19 16:20:28 UTC
It was very late in the evening when I said "ConditionPathIsDirectoryNotEmpty" was broken... that's because the actual option is called "ConditionDirectoryNotEmpty", and it works just fine.


I see 2 workable solutions to this issue:

1. Set `ConditionDirectoryNotEmpty=!/etc/pki/entitlement-host` in the [Unit] section of rhsmcertd to avoid service activation when host entitlements are available, or

2. Have a separate set of container presets that avoid enabling this service at all.

Comment 13 RHEL Program Management 2020-12-15 07:33:39 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.