Bug 1297363

Summary:	disable statements in system-preset files don't run
Product:	[Fedora] Fedora	Reporter:	Yaniv Bronhaim <ybronhei>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	johannbg, lnykryn, msekleta, s, systemd-maint, tomek, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-17 08:35:00 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:
Bug Blocks:	1167322

Description Yaniv Bronhaim 2016-01-11 10:26:32 UTC

Description of problem:
Having service x (x.service) preset file installed under /usr/lib/systemd/system-preset (e.g 85-x.service) with disable statement (such as "disable y.service") doesn't work - running "systemctl preset x.server" when y.service is enabled will do nothing. however, enable statements work alright.

specific example is vdsmd - see Bug #1167322

Version-Release number of selected component (if applicable):
systemctl --version returns
systemd 219

How reproducible:
100% over f23 and centos7

steps for reproduction:
 - systemctl enable y.service

 - cat /usr/lib/systemd/system-preset/85-x.preset
disable y.service

 - runnint "systemctl preset x.server"
does nothing when service is enabled

Expected results:
y.service unit file should be disabled

Comment 1 Zbigniew Jędrzejewski-Szmek 2016-01-11 13:48:59 UTC

Hm, is seems that you expect the preset config name file to somehow influence what's get enabled by 'systemctl preset'. The name if purely informative, and does not matter (apart from determining the order of priority).

Also, calling 'systemctl preset x' changes only x, not other services.

Comment 2 Yaniv Bronhaim 2016-01-14 10:26:15 UTC

does it mean that I can't install by x a preset file for service x that disable service y ? 
If so, and I want to disable service y after installing x, do I need to explicitly call to systemctl disable y.service ?

Comment 3 Jóhann B. Guðmundsson 2016-01-15 07:47:57 UTC

@Zbigniew he's failing to understand that preset files should only be used on products/distribution level to overwrite components default enable/disable but for concept like preset to fundamentally work you need to have distribution defaults of everything is disabled ( which is not the case for Fedora ).

All of this stems from the fundamental problem that you can install two ( or more ) components that conflict with each other in any shape or form in the first place ( or cant remove the conflicting component due to bad packaging dependency's ) so people fall into the rabit hole of chasing those conflict further down the stack in futile attempts to work around them.  

Here he's trying to workaround those conflicts using systemd by creating 

XX-vsdm.preset
enable vdsm.service
disable ksmtuned.service

When in fact ksmtuned should be removed when vsdm get's installed.

Comment 4 Zbigniew Jędrzejewski-Szmek 2016-01-15 14:45:11 UTC

(In reply to Yaniv Bronhaim from comment #2)
> does it mean that I can't install by x a preset file for service x that
> disable service y ?
You can, but it doesn't make much sense.

> If so, and I want to disable service y after installing x, do I need to
> explicitly call to systemctl disable y.service ?
It's not very elegant to modify service state of another package. But yes, that's the way to do it if you must.

Like Jóhann says, presets can't be really used to switch things at package installation time.

Comment 5 Yaniv Bronhaim 2016-01-17 08:35:00 UTC

Ok, Thanks for the explanation