Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1054161 - RFE: support .d/ unit drop-ins for [install] section settings
Summary: RFE: support .d/ unit drop-ins for [install] section settings
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-16 11:27 UTC by Honza Horak
Modified: 2015-09-08 13:54 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-08 13:54:15 UTC
Type: Bug


Attachments (Terms of Use)

Description Honza Horak 2014-01-16 11:27:05 UTC
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.

Comment 1 Lennart Poettering 2014-02-23 15:56:41 UTC
.d drop-ins are currently not support for settings in the [Install] section.

Comment 2 Honza Horak 2014-02-24 09:28:36 UTC
(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?

Comment 3 Fedora End Of Life 2015-05-29 10:31:55 UTC
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.

Comment 4 Zbigniew Jędrzejewski-Szmek 2015-05-29 16:20:59 UTC
(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.

Comment 5 Lukáš Nykrýn 2015-09-08 13:54:15 UTC
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.


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