ID: 312PHID: PHID-TASK-vjb3kpm5uwrbdcagipsuAuthor: PatrickStatus at Migration Time: resolvedPriority at Migration Time: Normal
What’s the correct location as package upstream when extending systemd unit files? /etc/systemd/system/unit.service.d or /lib/systemd/system/unit.service.d?
I might have made a mistake in T306 (pull ).
Figuring this out is important, so I can submit a fixed pull request and also because I plan to use similar overrides.
For example, timesync should extend the systemd unit file sdwdate.service by [Unit] (newline) Requires = msgcollector.service.
And another example, analogous to T306, swap-file-creator.service should be extended by [Unit] (newline) ConditionPathExists = !/usr/lib/qubes-whonix.
Example…
a)
/etc/systemd/system/rads.service.d/40_qubes.conf
sudo systemd-delta
[EXTENDED] /lib/systemd/system/rads.service → /etc/systemd/system/rads.service.d/40_qubes.conf
b)
/lib/systemd/system/rads.service.d/40_qubes.conf
sudo systemd-delta
[EXTENDED] /lib/systemd/system/rads.service → /lib/systemd/system/rads.service.d/40_qubes.conf
2015-05-17 17:04:38 UTC
My understanding is distribution package file go in /lib/systemd/system.
Administrator or local files go in /etc/systemd/system
Users can further extend within home directory
If you are simply extending a unit file; adding some extra condition, modifying its behaviour, over-riding the normal behaviour (adding an alias) to that what is published by upstream, the configuration files would go in /etc/systemd/system.
Your example of timesync above is not extending msgcollector or over-riding the behaviour of msgcollector in any way and only is requiring msgcollector to be available in order to start and therefore would be placed in /lib/systemd/system. The required statement should also be in the main timesync systemd unit file, not in a .d directory since it is required in all use cases
In the example of qubes needing an override, and since that would be local specific, the configuration override would go in /etc/systemd/system.
Anything that is putting a condition on ConditionPathExists = !/usr/lib/qubes-whonix, should not be included in upstream package at all, and qubes-whonix should be responsible to add the condition in /etc/systemd/system so I would need to know which files I should be doing this for. So far I it has rads and whonix-initializer
2015-05-18 11:31:06 UTC
Your example of timesync above is not extending msgcollector or over-riding the behaviour of msgcollector in any way
Yes, and that’s okay.
and only is requiring msgcollector to be available in order to start and therefore would be placed in /lib/systemd/system.
The intention is “if timesync is installed [which is an sdwdate gui plugin], then sdwdate.service requires msgcollector.service be running”. I guess that’s working.
The required statement should also be in the main timesync systemd unit file, not in a .d directory since it is required in all use cases
timesync is not a daemon, doesn’t have a systemd unit file.
In the example of qubes needing an override, and since that would be local specific, the configuration override would go in /etc/systemd/system.
Yes. That way also advanced users who want to undo that setting can do that more easily by deleting the file from /etc.
Anything that is putting a condition on ConditionPathExists = !/usr/lib/qubes-whonix, should not be included in upstream package at all, and qubes-whonix should be responsible to add the condition in /etc/systemd/system so I would need to know which files I should be doing this for. So far I it has rads and whonix-initializer
Yes. By your previous choice (initial implementation of qubes-whonix), I think that is rads, whonix-initializer and swap-file-creator.
2015-05-18 11:32:50 UTC