On Tue, 7 Mar 2017 01:45:08 +0100
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?
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: [...]
Regards,
Stefan
How nice. Unfortunately, when you are modifying a systemd service and look at systemd.service(5) there is nothing about that. Given systemd has a dozen of these man pages I would expect a cross-link to the explanation. But in systemd.service you get "A number of options that may be used in this section are shared with other unit types. These options are documented in systemd.exec(5), systemd.kill(5) and systemd.resource-control(5)." Nothing about systemd.unit. It's only mentioned in the generic See Also section and far from prominent there. So yes, an additional paragraph there as seen in systemd.unit(5) or possibly just link to the explanation there could potentially save everyone a lot of trouble. A package can ship these override files prefilled with commented-out defaults so you can see them in the file list just like it ships /etc/default files. There is very little awareness of this feature. When you ask about changing service files all you hear is "copy it to /etc/.. and edit it". I have read a few systemd tutorials when migrating to systemd and I have no idea this exists. So while systemd enthusiasts that read everything about systemd from cover to cover and back again may know the casual packager or administrtator who has had systemd shoved down their throat by the committee which decides the default init system of their distro just reads the systemd.service(5), writes a service definition which may even work with some luck, rants how useless maintaining that service is, and moves on. This results in a lots of rants available when you ask WTF you should do to write a service file for this piece of software that has worked flawlessly for 25 years but now cannot be started on your system because it does not have a systemd service file. Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org