Masking a systemd service is the hard block that prevents a unit from starting by hand, through dependencies, or through boot-time activation. Removing that block is the recovery step when maintenance is finished or when a vendor service needs to be allowed to run again.
The systemctl unmask command removes the /dev/null symlink that systemd uses to mark a unit as masked. After the mask is gone, the unit returns to its normal unit-file state such as disabled, enabled, or static, and systemd can load it from the real unit file again.
Examples below use a generic queue-worker.service unit name to keep the flow readable. Replace it with the real unit name on the host, add sudo for system services, and use systemctl --user for per-user units. Unmasking only removes the block itself: it does not start the service, re-enable it for boot, or restore a missing unit file, so a unit that still shows not-found after unmasking must be reinstalled or restored separately.
Steps to unmask a service with systemctl:
- Open a terminal session on the host that runs systemd.
Use the full unit name such as queue-worker.service or nginx.service. Current upstream systemctl behavior expects unit names here, not file paths such as /etc/systemd/system/queue-worker.service.
- Confirm that the unit is actually masked before changing it.
$ systemctl is-enabled queue-worker.service masked
masked is the persistent /etc/systemd/system form. masked-runtime is the temporary /run/systemd/system form that disappears after reboot unless it is removed earlier.
Related: How to mask a service in systemd
- Check the normalized load state when you want to confirm that the block applies at the unit-file layer.
$ systemctl show -p LoadState -p UnitFileState queue-worker.service LoadState=masked UnitFileState=masked
A LoadState=masked result means systemd is still resolving the unit name to /dev/null instead of the real unit file.
- Remove the mask from the unit.
$ sudo systemctl unmask queue-worker.service Removed "/etc/systemd/system/queue-worker.service".
When the service reports masked-runtime, use sudo systemctl unmask --runtime queue-worker.service to remove the temporary mask under /run/systemd/system. A reboot also clears a runtime mask.
systemctl unmask normally reloads the manager configuration automatically. A separate systemctl daemon-reload is only needed if you intentionally used --no-reload or changed unit files in the same maintenance window.
- Confirm that the unit returned to its underlying unit-file state.
$ systemctl is-enabled queue-worker.service disabled
$ systemctl show -p LoadState -p UnitFileState queue-worker.service LoadState=loaded UnitFileState=disabled
After unmasking, the unit commonly returns to disabled, but enabled or static are also valid depending on how the service was installed before it was masked.
- Start the service now if it should begin running again immediately.
$ sudo systemctl start queue-worker.service $ systemctl is-active queue-worker.service active
unmask only makes the unit eligible to start again. It does not activate the service and it does not support --now, so start or enable the unit separately after the mask is removed.
If the service should also start on future boots, use sudo systemctl enable --now queue-worker.service instead of start alone.
- Inspect the status and recent journal when the service still refuses to run after unmasking.
$ systemctl status --no-pager --full queue-worker.service * queue-worker.service - Queue Worker Service Loaded: loaded (/usr/lib/systemd/system/queue-worker.service; disabled; preset: enabled) Active: active (running) since Mon 2026-04-13 13:13:51 UTC; 10ms ago ##### snipped #####If the status header shows Loaded: not-found after unmasking, the blocking symlink is gone but the real unit file is still missing.
systemctl status is the fastest human-readable follow-up, and journalctl -u unit.service is the cleaner next step when the start job fails or times out.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
