LinuxCommandLibrary

systemctl-unmask

Re-enable masked systemd units

TLDR

Unmask a service

$ systemctl unmask [service_name]
copy

Unmask and start a service immediately
$ systemctl unmask [service_name] --now
copy

Unmask a user service
$ systemctl unmask [service_name] --user
copy

SYNOPSIS

systemctl unmask [OPTIONS] UNIT...

PARAMETERS

UNIT...
    One or more systemd unit names (e.g., nginx.service, multi-user.target).

--runtime
    Unmask the unit only until the next system reboot. The change will not persist across reboots.

--now
    Attempt to start the unit immediately after unmasking. This option is only effective if the unit was previously enabled or is configured to start automatically.

DESCRIPTION

systemctl unmask is a command used to reverse the effect of a systemctl mask operation on one or more systemd unit files. When a unit is "masked," it means that symbolic links are created from the unit file's location (e.g., /etc/systemd/system/multi-user.target.wants/nginx.service) to /dev/null. This effectively prevents the unit from being started, either manually or as a dependency, because systemd interprets /dev/null as a "black hole" where the unit cannot execute. Masking is often used to permanently disable critical services, prevent unwanted services from running, or during troubleshooting.

Unmasking a unit removes these symbolic links, restoring the unit file to its original location and allowing systemd to manage it normally again. It does not automatically start the unit or enable it to start on boot. After unmasking, you typically need to use systemctl enable to configure it to start automatically on system boot and systemctl start to activate it immediately. The unmask command is crucial for regaining control over units that were previously locked down.

CAVEATS

Unmasking a unit only makes it eligible to be started; it does not automatically start the unit or enable it for boot. To achieve this, you typically need to follow up with systemctl enable and systemctl start commands. If the unit was previously enabled, unmasking it will make it eligible to start on the next reboot. Using the --now option can have immediate effects, potentially starting services that might not be ready or could interfere with other running processes.

UNDERLYING MECHANISM

When a unit is masked, a symbolic link is created from its configuration path (e.g., /etc/systemd/system/nginx.service) to /dev/null. The systemctl unmask command simply removes this symlink, restoring the unit's ability to be managed by systemd. You can manually inspect these symlinks by checking directories like /etc/systemd/system/.

CHECKING UNIT STATUS

To determine if a unit is currently masked, you can use systemctl status UNIT and look for 'masked' in its state, or use systemctl list-unit-files --state=masked to see all masked units.

HISTORY

The systemctl command and the concept of masking/unmasking units are integral parts of systemd, which was developed by Lennart Poettering and Kay Sievers. systemd was first introduced in Fedora 15 in 2011 and has since been widely adopted across most major Linux distributions, replacing older SysVinit and Upstart systems. The mask and unmask functionalities have been core features from systemd's early development, providing robust control over service lifecycles.

SEE ALSO

systemctl mask(1), systemctl enable(1), systemctl disable(1), systemctl start(1), systemctl stop(1), systemctl status(1)

Copied to clipboard