| 1 |
On Fri, Aug 26, 2022 at 4:57 AM Florian Schmaus <flow@g.o> wrote: |
| 2 |
> |
| 3 |
> While then can not be modified, settings made in /usr/lib/systemd/system |
| 4 |
> can be overridden by the sysadmin by placing a file in /etc/systemd/system. |
| 5 |
> |
| 6 |
> I am not aware of a reason why a package manger should install systemd |
| 7 |
> configuration files under /etc. |
| 8 |
> |
| 9 |
|
| 10 |
I'd say the biggest use case would be settings that typically require |
| 11 |
modification that are needed at service launch time. Think of |
| 12 |
packages that stick stuff in /etc/conf.d for non-systemd settings. |
| 13 |
|
| 14 |
An example of this can be found in sys-devel/distcc/files/distccd.service.conf |
| 15 |
|
| 16 |
Sure, you could stick that in /usr, and then the user could copy it to |
| 17 |
/etc (or use systemctl edit). However, since it is something that is |
| 18 |
basically intended to be edited you can argue that it makes more sense |
| 19 |
to just stick it in /etc. This also means that if a new setting gets |
| 20 |
added the user will be made aware via config protection. For a |
| 21 |
drop-in that changes in /usr the user would receive no notice of this, |
| 22 |
and the new settings would get merged with theirs or ignored depending |
| 23 |
on how it was done. |
| 24 |
|
| 25 |
For a distro override that wouldn't typically be modified, like |
| 26 |
integrating one service with another that only service the local host, |
| 27 |
then maybe /usr would make more sense. |
| 28 |
|
| 29 |
Using systemctl edit is also a little awkward due to the way it |
| 30 |
presents you with the original config at the bottom and you have to |
| 31 |
copy the stuff you want to modify to the top. I assume it lets you |
| 32 |
copy comments as well, but it is a bit like opening up two editors and |
| 33 |
copying from a skeleton file to a new file, vs just editing one in |
| 34 |
place. Well, except you aren't working between two files but editing |
| 35 |
at two places in one file, so if your editor doesn't handle split |
| 36 |
screen well you will scroll around a lot if the file is large. |
| 37 |
|
| 38 |
I don't have very strong feelings about this either way, but I can |
| 39 |
definitely see why things were done the way they're done. I'm not |
| 40 |
sure if there are any examples of fairly large drop-ins in /etc that |
| 41 |
we install but I'd probably want to look at one before changing the |
| 42 |
approach to see if it makes sense. |
| 43 |
|
| 44 |
-- |
| 45 |
Rich |
Archives