07.03.2017 03:45, Stefan Bruens пишет:
On Montag, 6. März 2017 13:20:57 CET Michal Suchánek wrote:
On Mon, 27 Feb 2017 19:52:28 +0100
Perhaps it is the systemd mechanism by which services in /usrsomething can be superseded by placing the same service file under /etcsomething. Erasing those files on /etc would revert to factory settings, no?
And it also allows the admin to replicate the changes easily on another machine, and to do updates without local modifications being erased.
That also means updates without service updates being applied.
Because you copy the *WHOLE* service, make changes, and any updates to the service are lost on update.
Sane services are configurable so you put a file in /etc/ that configures the service and do not change the service itself unless you need to fix some error in the service definition.
But nobody writes systemd services that accept configuration so you have to fix the service definition to be configurable and only then you can configure it /o\
Why are the systemd haters always claiming stuff without once reading the man pages?
Oh, now I become systemd hater ... how funny ...
man systemd.unit: EXAMPLES ... Example 2. Overriding vendor settings [...] Suppose there is a vendor-supplied unit /usr/lib/systemd/system/ httpd.service with the following contents: [...]
The first possibility is to copy the unit file to /etc/systemd/system/httpd.service and change the chosen settings: [...]
Alternatively, the administrator could create a drop-in file /etc/systemd/system/httpd.service.d/local.conf with the following contents: [...]
Unfortunately ... 1. Not all settings can be overridden. Choice of which can is rather arbitrary. 2. Not all settings can be easily augmented. You need to completely replace existing setting with new one. Which returns us to the same problem on smaller scale. 3. Individual values in multi-value settings cannot be removed - you need to remove *all* values and add the ones you need. We are back at square one. 4. This makes unit definition be spread across the multiple files and directories without clear API how to collect them (and note - you suddenly really need API for what was marketed as "simple plain text files"). One obvious case where it bites is initramfs generators - last time I have checked dracut did not even attempt to collect all those pieces. Which means that if your service is needed in initrd and you changed it then dracut won't include your changes. And if your service happens to remain active across root switch, you will now have effectively different service running - but with the same name and same description and without any clear way to know it. BTW regarding 4 - same problem happens when you change unit definition and do daemon-reload. What you now see in unit file *and in systemctl show output* does not match what had actually been started and is running currently. I wish good luck to support stuff that has to debug it ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org