Suppose a package provides whatever.service file so certain events (including whatever.socket) cause a daemon to start with a certain configuration.
I want to disable this completely. In particular, I want the old socket and any other unit files that might refer to this service by name to be unable to start the daemon.
Instead, I want to create my own unit files for this daemon with a different .socket unit and different environment variables. I also want my override to automatically take account of possible upstream updates to the original unit file (which my current solution of copying whatever.service as whatever-modified.service and editing it unfortunately does not provide).
If I create the following symlinks and files:
/etc/systemd/system/whatever.service → /dev/null
/etc/systemd/system/whatever-modified.service → /usr/lib/systemd/system/whatever.service
/etc/systemd/system/whatever-modified.service.d/fix.conf
systemd considers the new service to be masked as well and refuses to start it. How to avoid this?
Best Answer
If you create
/etc/systemd/system/whatever.service
, it already automatically and completely overrides any corresponding/usr/lib/systemd/system/whatever.service
- symlinking to/dev/null
is just a special case of that.If you want to override just parts of the existing
/usr/lib/systemd/system/whatever.service
, taking into account possible future updates, you can create/etc/systemd/system/whatever.service.d/fix.conf
with your overrides/additions. It will automatically be applied against/usr/lib/systemd/system/whatever.service
if/etc/systemd/system/whatever.service
does not exist.Note that some settings, like
ExecStart=
may appear multiple times, and if you wish to override the existingExecStart=
line instead of adding another, yourfix.conf
will need to look like this:The first empty
ExecStart=
line tells systemd "I want to remove the original ExecStart parameter, not just add a new one."And of course, remember to always run
systemctl daemon-reload
after making changes to.service
files or.service.d
directories or their contents. Otherwise the changes won't take effect.Running
systemctl cat whatever.service
may be helpful by showing at once all the parts from which the service definition is ultimately built up.