Description of problem: I'm trying to define Also= parameter in a service by extending original service file using .../foo.service.d/bar.conf, but it doesn't work the same as if Also= is defined directly in the original service file. # cat /etc/systemd/system/foo1.service [Unit] Description=Foo1 [Service] Type=oneshot ExecStart=/bin/true [Install] WantedBy=multi-user.target Also=bar.service # cat /etc/systemd/system/foo2.service [Unit] Description=Foo2 [Service] Type=oneshot ExecStart=/bin/true [Install] WantedBy=multi-user.target # cat /etc/systemd/system/foo2.service.d/bar.conf [Install] Also=bar.service # cat /etc/systemd/system/bar.service [Unit] Description=Bar [Service] Type=oneshot ExecStart=/bin/true [Install] WantedBy=multi-user.target Version-Release number of selected component (if applicable): systemd-208-9.fc20.x86_64 How reproducible: every-time Steps to Reproduce: 1. systemctl enable foo1 2. systemctl disable foo1 3. systemctl enable foo2 4. systemctl disable foo2 Actual results: ln -s '/etc/systemd/system/foo1.service' '/etc/systemd/system/multi-user.target.wants/foo1.service' ln -s '/etc/systemd/system/bar.service' '/etc/systemd/system/multi-user.target.wants/bar.service' rm '/etc/systemd/system/multi-user.target.wants/bar.service' rm '/etc/systemd/system/multi-user.target.wants/foo1.service' ln -s '/etc/systemd/system/foo2.service' '/etc/systemd/system/multi-user.target.wants/foo2.service' rm '/etc/systemd/system/multi-user.target.wants/foo2.service' Expected results: ln -s '/etc/systemd/system/foo1.service' '/etc/systemd/system/multi-user.target.wants/foo1.service' ln -s '/etc/systemd/system/bar.service' '/etc/systemd/system/multi-user.target.wants/bar.service' rm '/etc/systemd/system/multi-user.target.wants/bar.service' rm '/etc/systemd/system/multi-user.target.wants/foo1.service' ln -s '/etc/systemd/system/foo2.service' '/etc/systemd/system/multi-user.target.wants/foo2.service' ln -s '/etc/systemd/system/bar.service' '/etc/systemd/system/multi-user.target.wants/bar.service' rm '/etc/systemd/system/multi-user.target.wants/bar.service' rm '/etc/systemd/system/multi-user.target.wants/foo2.service' Additional info: Hint for decoding long expected results: missing bar.service is not enabled when foo2 is being enabled.
.d drop-ins are currently not support for settings in the [Install] section.
(In reply to Lennart Poettering from comment #1) > .d drop-ins are currently not support for settings in the [Install] section. Any particular reason for that or just lack of manpower to implement this?
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Honza Horak from comment #2) > Any particular reason for that or just lack of manpower to implement this? Lack of manpower mostly, but I think that there's a bit of uncertainty as to whether this is needed.
From similar rhel Bugzilla: (In reply to Lennart Poettering from comment #1) > I am not convinced this is really a good idea. The [install] section of unit > files contains directives how to enable and disable units, as suggestions > made by the author of the unit file, and that's about it. Currently, we only > allow using it in the unit file shipped in /usr, and not in extensions or > overriding unit files in /etc. That's because /etc is the space for admin > configuration, while /usr is the space for vendor configuration. If a > user/admin wants to extend a unit file, or whther it is enabled/pulled in by > something, he can do so directly in /etc, there's no need to extend the > [install] logic at all, since the [install] logic is really just about > suggesting good defaults to the admin, and that's it. I mean, why would an > admin not just make the changes he wants to make directly in 7etc? Why would > he want to changet the suggestions the vendor makes for him, and then apply > those? Why this indirection, the extra step of altering the vendor > suggestions? That makes little sense, I think. > > I think what would make sense would be to make it easier to make manual > changes to /etc. For example, we could add "systemctl add-wants" or so, > which creates a symlink in /etc that pulls in some unit from some other unit > or so. This would be much easier for the admin to do than asking him to > first extend [install] and then use "systemctl enable"... > > So yeah, I think we should figure out what precisely people want to extend > [install] for. If it's only about adding WantedBy= and RequiredBy= then a > high-level "systemctl add-wants" and "systemctl add-requires" would be the > better choice. > > And in fact, that's actually on the todo list, though nobody has worked on > it so far. And we now have add-wants so lets close this bug.