There is a service I want to run only when another service fails ([Unit] OnFailure=foo), but I don't want this service (foo) to start up automatically on boot. One option is running systemctl disable foo, but I'm looking for another way.
Background: I am creating an OS image, and I don't want to have to boot the machine up, run that command (systemctl disable foo), then shut it down before declaring my image final.
systemctl enable works by manipulating symlinks in /etc/systemd/system/ (for system daemons). When you enable a service, it looks at the WantedBy lines in the [Install] section, and plops symlinks in those .wants directories.
systemctl disable does the opposite.
You can just remove those symlinks—doing that by hand is fully equivalent to using systemctl disable.
All services are "disabled" by default; "enablement" is opt-in.
If foo.service is your custom service, then it won't be started unless explicitly pulled in by something (like the OnFailure= directive), and you should not "disable" anything.
You can use systemctl start ServiceName.service and systemctl stop Service.Name.service to start and stop a service respectively. In contrast to systemctl enable ... and systemctl disable ..., the start and stop commands only last for the current session, therefore when you reboot the machine the changes wont be saved.
There's also the options of masking and unmasking, but someone with more experience and know-how should explain that instead of me.
sudo systemctl mask service_to_mask sudo systemctl unmask service_to_unmask
I hope this is correct. But this type of thing needs to be in this conversation for completeness.
Masking uses diversion to /dev/null which is pretty nice.
If I remember correctly, services can be stopped, disabled, and masked in the same session.
/dev/null. Masking allows systemd to sort of 'skip' that specific service as if it weren't there, but without deleting anything (systemctl will know it's there, and report it's masked, etc.). There might be some other reasons for masking vs. disabling services, which I'm also not the best person to explain them... that's the limit of my knowledge, I'm afraid.