Mask and inherit the same systemd unit

Question

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?

Answer 1

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 existing ExecStart= line instead of adding another, your fix.conf will need to look like this:

[Service]
ExecStart=
ExecStart=/your/custom/command

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.