When I run the command sudo systemctl list-unit-files (I think the sudo is optional), I get output which shows all services and their state.

Here is a snippet from my machine:

UNIT FILE                                  STATE
debian-fixup.service                       static  
debug-shell.service                        disabled
display-manager.service                    enabled 
dns-clean.service                          enabled 
dsmcad.service                             enabled 
emergency.service                          static  
failsafe-x.service                         static  
friendly-recovery.service                  masked  
fuse.service                               masked  
gdm.service                                masked  
getty-static.service                       static  
[email protected]                             enabled 
gpsd.service                               indirect
[email protected]                           static  
gpu-manager.service                        enabled 
halt-local.service                         static  
halt.service                               masked  
hostname.service                           masked

I wonder why some services are in the "masked" state. I think this means, "this is better than 'disabling', because the service cannot be started, neither by hand or by systemd".

How can I get more information about the state of a service unit?

Who has put the units into their respective state?

I tried, for example, sudo systemctl help dsmcad - that only brings up the documentation = ... line from the unit file. /etc/systemd/system/dsmcad.service

Note: Here I know exactly what dsmcad service is and what it does, I have installed it myself. I am more interested in a general solution.

5 Answers 5


mask is a stronger version of disable. Using disable all symlinks of the specified unit file are removed. If using mask the units will be linked to /dev/null. This will be displayed if you check e.g. by systemctl status halt.service. The advantage of mask is to prevent any kind of activation, even manual.

Caution: systemctl list-unit-files is listing the state of the unit files (static, enabled, disabled, masked, indirect) and has nothing to do with the state of the service. To have a look at the services use systemctl list-units.

  • 19
    Please also explain how to remove the masked state, if desired.
    – erikbstack
    Commented Mar 22, 2017 at 8:02
  • 38
    There is a mask and an unmask command that can be used with systemctl. So just do systemctl unmask name_of_service.service. Commented Mar 23, 2017 at 17:53
  • 3
    doing systemctl unmask name_of_service.service completely removed my service definition file from /etc/systemd/system/, so now I need to add it back again. If it becomes masked again, I'll be stuck in a loop o.O
    – Eldamir
    Commented Jun 12, 2018 at 9:22
  • 3
    Hi Eldamir, in /etc/systemd/system are just symbolic links of services. Your should add the *.service file to /lib/systemd/system from where it will be linked to /etc/systemd/system if you enable the service. mask is creating a link to /dev/null and unmask is removing this link from /etc/systemd/system and obviously it makes no difference if someone put a file there. Commented Jun 13, 2018 at 12:26

'mask' is a state of unit files which is considered as the "third level of off" (stop-1st, disable-2nd, mask-3rd). The services labeled as masked can neither be started manually (using the start command) nor by systems (at system boot). Therefore, use caution when employing the systemctl mask command on a service.


Since you are requesting information about the masked state, it is important to mention that it can be observed in a service that after started, had it definitions modified, reload (systemctl daemon-reload) and the new state is NOT ok. One easy example to understand it is the following scenario:

a) the service is running well (already started)
b) edit the service definition file and delete everything in its contents
c) reload
d) state masked will be observed too

Hence, the masked state may be originated from a improper service definitions. Therefore, the user may induce unmasked state by editing improperly the service.

Observation: I'm not sure if it happens on purpose or it is a simple bug (default option), but it may be some interesting info to share


hostname.service is masked as redundant because systemd sets the hostname (from /etc/hostname) very early on during startup.

This setting is provided by the Debian systemd package.

$ ls -l /lib/systemd/system/hostname.service
lrwxrwxrwx 1 root root 9 Apr  8 22:47 /lib/systemd/system/hostname.service -> /dev/null
$ dpkg-query --search /lib/systemd/system/hostname.service
systemd: /lib/systemd/system/hostname.service

Similarly, Debian can now run without a shell script to halt the system, it's handled by systemd-shutdown (source code here) instead.

If a service has been masked manually, the mask will be installed in /etc/systemd/system instead.

Services are also masked when they are removed on Debian/Ubuntu. I don't know why.

  • 1
    Masking vs. removing of services comes with the difference of removing vs. purging a package. In the first case the config-files are kept and thus it might be potentially dangerous to activate a service by mistake (as the service file might still be in the config files). A purged package will also have the service files removed and not masked.
    – FelixJN
    Commented Nov 15, 2019 at 23:48

Did you create your own .service file?

Note: If you have created your own systemd .service file it might be that your file contains a syntax error, or is blank. This appears to cause the same error message to be shown, regardless of the fact that the problem has nothing to do with the service file being explicitly set as masked.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .