Story / scenario opener
You ran systemctl disable on a service, rebooted, and the service is still running. Or you have a misbehaving daemon that crashes your boot sequence, and you need to stop it from starting no matter what triggers it. disable turns off the default start. It does not stop a timer from waking the service up. It does not stop a socket from activating it on connection. It does not stop another service from pulling it in as a dependency. mask welds the door shut. It tells systemd the unit does not exist. The service cannot start. It cannot be pulled in. It is gone from the runtime perspective until you remove the mask.
What's actually happening
systemd manages startup through symlinks. When you enable a service, a symlink appears in a .wants directory inside /etc/systemd/system/. When you disable it, that symlink is removed. The unit file itself remains in /usr/lib/systemd/system/. Other units can still start your service. A timer might trigger it. A socket might activate it. A dependency in another unit might require it. disable only stops the automatic start at boot.
Masking creates a symlink in /etc/systemd/system/ pointing to /dev/null. systemd reads /etc/ before /usr/lib/. When it encounters a unit file that is a symlink to /dev/null, it treats the unit as non-existent. It refuses to load the unit. It refuses to start the unit. It refuses to allow the unit to be pulled in by dependencies. The mask is a hard block at the core of the manager.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. Masking writes a symlink to /etc/, which is the correct override path. Your mask takes precedence over the shipped unit file. This is how the override mechanism is designed to work.
The fix
Mask a service to prevent it from starting under any circumstance. Unmask it to restore normal behavior.
Here is how to mask a service and verify the symlink is in place.
# Mask the service to block all activation paths
sudo systemctl mask myservice.service # Creates /etc/systemd/system/myservice.service -> /dev/null
# Verify the mask exists and points to null
ls -l /etc/systemd/system/myservice.service # Confirms symlink target is /dev/null
Here is how to remove the mask and restore the unit.
# Remove the mask to restore the unit file
sudo systemctl unmask myservice.service # Deletes the /dev/null symlink, revealing the original unit file
# Check that the mask is gone
systemctl status myservice.service # Should show "Loaded: loaded" instead of "masked"
Unmasking does not re-enable the service. The service returns to its previous state. If it was disabled before masking, it remains disabled after unmasking. You may need to run systemctl enable after unmasking if you want the service to start automatically again.
Verify it worked
Run systemctl status to confirm the mask is active. Look for Loaded: masked in the output.
● myservice.service - My Example Service
Loaded: masked (Reason: Unit myservice.service is masked)
Active: inactive (dead)
If you see Loaded: masked, the service is locked out. systemd will reject any attempt to start it. If you try to start a masked service, you will get an immediate error.
Failed to start myservice.service: Unit myservice.service is masked.
This error is not a bug. This is the mask working. The service is blocked.
Check the status before you restart. systemctl status shows recent log lines and the current state in one view. Always check status before restart. If the state says masked, a restart command will fail.
Common pitfalls and what the error looks like
Masking breaks dependencies. If foo.service requires bar.service, and you mask bar, foo will fail to start. systemd will log a dependency failure. This is why masking is dangerous. You can break critical parts of the system by masking a service that other units depend on.
Check dependencies before you mask. Use list-dependencies to see what relies on the service.
# Check reverse dependencies before masking
systemctl list-dependencies --reverse myservice.service # Shows units that require or want this service
# Mask only if you accept that dependent units will fail
sudo systemctl mask myservice.service
If you mask a service and a dependent unit fails, the error will appear in the journal. Run journalctl -xe to read the logs. The -x flag adds explanatory text and the -e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. This command shows you exactly which dependency failed and why.
-- Subject: Unit myservice.service has failed
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit myservice.service has failed.
--
-- The result is dependency.
--
-- The job identifier is 1234 and the job result is dependency.
The result dependency means a required unit was not available. If you masked the required unit, this is expected behavior. Unmask the dependency to fix the failure.
Masking critical services can leave you unable to boot or log in. If you mask dbus.service, your desktop environment will fail. If you mask systemd-journald, logging breaks. If you mask NetworkManager, you lose network access. Masking is nuclear. Use it when you mean it.
If you mask a critical service and lose access, you can still recover. Boot into the emergency shell or use a live USB. Mount the root filesystem. Run the unmask command with the --root flag.
# Mount root if in live USB environment
sudo mount /dev/nvme0n1p2 /mnt # Mount the Fedora root partition
# Unmask the service from the mounted filesystem
sudo systemctl unmask --root=/mnt myservice.service # Operates on the mounted root instead of the running system
The --root flag tells systemd to operate on the specified directory tree instead of the running system. This is the standard recovery pattern for fixing systemd configuration from a rescue environment.
When to use this vs alternatives
Use systemctl disable when you want to stop the service from starting at boot but allow manual starts or dependency pulls. Use systemctl mask when you need to guarantee the service never starts, even if another unit tries to pull it in as a dependency. Use systemctl stop when you need to kill a running instance immediately without changing the boot configuration. Use systemctl unmask when you are ready to restore the service to its normal state and remove the hard block. Use systemctl enable after unmasking if you want the service to start automatically again.