systemd setting overrides
Monday, June 17. 2019
In couple past posts of mine, I've instructed people to do alter systemd service descriptions. Examples from Randomness in computers and Handling /run with systemd. As we all know, systemd is quite a beast. It just keeps on giving complexity as we stumble along trying to grasp all of it.
For example:
To add more command arguments to rngd.service, you can do what I instructed earlier. You can copy /usr/lib/systemd/system/rngd.service to /etc/systemd/system/, edit the file and do a systemctl daemon-reload to update the changes.
If you want to choose more systemd'ic (Python developers always say "pythonic") way, you can do a:
systemctl edit rngd
This command will open a text-editor. The editor is your default one from EDITOR environment variable, or if you haven't picked one, a default will be chosen for you by your favorite Linux distro vendor.
What you should make the text file contain, is following three (3) lines:
[Service]
ExecStart=
ExecStart=/sbin/rngd -f --rng-device=/dev/TrueRNG --fill-watermark=4000
Those lines will re-define service description. First by clearing out the previous value(s) and then defining a new one. On save, this setting will take automatically effect and you don't have to do anything else. Also, this setting is persisted in a file called /etc/systemd/system/rngd.service.d/override.conf. Of course, you can create that particular file yourself, but then the familiar systemctl daemon-reload is needed to make your changes stick.
Nice and easy! 
Jon on :
Jari Turkia on :
Why would you assume, that anything in Linux or systemd would be easy or nice or both? In Linux-world you must be able to grasp the idea, that the next guy is doing the same thing you're doing, but in a completely different way.
In systemd, the original effective definition file is easily available with systemd status -command. If you didn't know that or cannot do a split edit for that file while looking at the override editor, you're definitely in the wrong league here.
The logic here is, that if you want to do a small change, this override-procedure might be the correct tool for a problem. If the stuff you're overriding is for multiple sections of the service/socket/automount/mount/path/timer definition, then going the old way might be better. My idea here is to shine some light to options you can use at your own discretion. Knowing about this and choosing not do use it, is up to you.