Bug 1163968

Summary: rhsmcertd.service should be enabled by default in systemd presets
Product: Red Hat Enterprise Linux 7 Reporter: William Poteat <wpoteat>
Component: redhat-releaseAssignee: Lubos Kocman <lkocman>
Status: CLOSED DUPLICATE QA Contact: Release Test Team <release-test-team-automation>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: alikins, bcourt, bkearney, dgoodwin, extras-qa, jbowes, khowell, lnykryn, luto, systemd-maint-list
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1094932 Environment:
Last Closed: 2017-02-07 11:38:51 UTC Type: ---
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: 1271839    
Bug Blocks: 1090684, 1094932, 1121117, 1378128    

Description William Poteat 2014-11-13 19:54:32 UTC
+++ This bug was initially created as a clone of Bug #1094932 +++

My query script thinks that subscription-manager has a script or trigger that directly enables a systemd unit using 'systemctl enable'.  It probably should not.  Please update this packages to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd).

If your package has an exception from FESCo permitting it to enable
itself, please make sure that the service in question is listed in the
appropriate preset file.

There is a general exception described here:

https://fedoraproject.org/wiki/Starting_services_by_default

If your package falls under the general exception, then it is possible
that no change is required.  Nevertheless, if you are relying on the
exception, please make sure that your rpm scripts are sensible.  The
exception is:

In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away"), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). An example of "runs once then goes away" service is iptables.

Given that this issue can affect Fedora 20 users who install your
package as a dependency, this bug should be fixed in Fedora 20 and
Rawhide.



-----------------------------------------------------------------------------------

Replacement of this scripting will require a change to systemd.rpm preset policy such that rhsmcertd.service is added.

Comment 1 Lukáš Nykrýn 2014-11-13 22:21:17 UTC
Why is this reported against systemd?

Comment 2 William Poteat 2014-11-14 12:46:58 UTC
Aren't the systemd folks resposible for the preset poicy list?

Comment 3 Lukáš Nykrýn 2014-11-14 12:57:18 UTC
Nope.

Comment 5 Adrian Likins 2015-08-13 13:56:55 UTC
Is there a particular order this and https://bugzilla.redhat.com/show_bug.cgi?id=1094932 need to happen in?

ie, if I change the subman post scripts to use systemd macros, does the systemd defaults have to change first? 

(If we change subman spec to use the macros without the systemd defaults, rhsmd will be disabled by default in builds until redhat-release-server updates the defaults correct?  Afaik, that should be fine assuming it will get changed before GA. Only downside is it might temporarily break some qe automation...)

Comment 6 Kevin Howell 2016-09-14 17:03:49 UTC
The preset should change before we change the packaging of subscription-manager, as a change to the preset won't affect the package negatively, but changing the package first will cause it to be disabled by default (as described in comment 5).

Therefore, I'm reversing the relationship of this bug and bug 1094932.

Comment 7 Kevin Howell 2016-09-21 15:55:01 UTC
Wrong bug. Apologies.

Comment 8 Lubos Kocman 2017-02-02 09:20:43 UTC
Adding devel ack+ based on comment in linked bug. We do have a lot of preset changes scheduled.

Lubos

Comment 9 Lubos Kocman 2017-02-07 11:38:51 UTC

*** This bug has been marked as a duplicate of bug 1271839 ***