Red Hat Bugzilla – Bug 1297363
disable statements in system-preset files don't run
Last modified: 2016-01-17 03:35:00 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
100% over f23 and centos7
steps for reproduction:
- systemctl enable y.service
- cat /usr/lib/systemd/system-preset/85-x.preset
- runnint "systemctl preset x.server"
does nothing when service is enabled
y.service unit file should be disabled
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.
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 ?
@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
When in fact ksmtuned should be removed when vsdm get's installed.
(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.
Ok, Thanks for the explanation