Bug 1297363 - disable statements in system-preset files don't run
disable statements in system-preset files don't run
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1167322
  Show dependency treegraph
 
Reported: 2016-01-11 05:26 EST by Yaniv Bronhaim
Modified: 2016-01-17 03:35 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-17 03:35:00 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 Yaniv Bronhaim 2016-01-11 05:26:32 EST
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 08:48:59 EST
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 05:26:15 EST
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 02:47:57 EST
@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 09:45:11 EST
(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 03:35:00 EST
Ok, Thanks for the explanation

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