110

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  
getty@.service                             enabled 
gpsd.service                               indirect
gpsdctl@.service                           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.

knb
  • 5,004

4 Answers4

115

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.

Kellerspeicher
  • 1,320
  • 1
  • 9
  • 8
  • 19
    Please also explain how to remove the masked state, if desired. – erikbstack Mar 22 '17 at 08:02
  • 37
    There is a mask and an unmask command that can be used with systemctl. So just do systemctl unmask name_of_service.service. – Kellerspeicher Mar 23 '17 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 Jun 12 '18 at 09: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. – Kellerspeicher Jun 13 '18 at 12:26
7

'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.

d. Quame
  • 71
4

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

Thiago Conrado
  • 388
3

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.

sourcejedi
  • 448
  • 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 Nov 15 '19 at 23:48