Content

Introductory

Linux services are programs running in the background, which do not have a separate user interface, but respond to the requests of other programs through some communication mechanism (mostly on the network). Some of these are called daemons, depending on their function. Services in modern Linux systems are called the systemd manages and a systemctl they can be started, stopped, etc. using a command.

In addition to starting and stopping services, the systemctl command includes many other functions, such as disabling, enabling, masking or unmasking services, etc. In this short troubleshooter, we'll cover masking and unmasking. To better understand the problem itself, we need to say a few words about masking itself.

Masking and unmasking of services

Masking services is another way to disable services. The difference is that, while in the case of disabling all of the services symbolic link is removed by the system, while in the case of masking these symbolic links are a / Dev / null point to an element. If we simply disable a service, it can still be started manually. And when we mask a service, it cannot be started manually. In other words, masking makes the service permanently unusable until it is re-discovered.

Services are disabled and enabled with the following commands:

sudo systemctl disable <unit név>
sudo systemctl enable <unit név>

Masking and revealing:

sudo systemctl mask <unit név>
sudo systemctl unmask <unit név>

Masking has security implications, because a service can not only be started manually, but other programs and services can also start them in the background as a result of certain events, etc. If we want to temporarily disable a service so that nothing can start it, masking is a good solution for this.

Now that we have said a few words tangentially about this, let's move on to the error phenomenon and its solution.

The symptom

A service was masked by the system systemctl unmask cannot be unlocked with a command. The command does not throw an error, but it also does not perform the unmask operation.

In my own example, the service "stuck" in this way was Chrome Remote Desktop, with the help of which we can remotely control other computers through the desktop.

When an update comes out for the package, it sometimes happens to me that the remote control does not start correctly at first. This usually happens when the /opt/google/chrome-remote-desktop/chrome-remote-desktop file, which had to be modified manually according to the description linked above, so that the remote control would connect to the current session and not get an empty desktop in a new session.

When this happens, I redo the changes to the file, which requires stopping Chrome Remote Desktop and restarting it for the changes to take effect. And this is when the error usually occurs: When I issue any of the following restart or start commands:

systemctl restart chrome-remote-desktop
systemctl start chrome-remote-desktop

I get the following error messages:

Failed to restart chrome-remote-desktop.service: Unit chrome-remote-desktop.service is masked.
Failed to start chrome-remote-desktop.service: Unit chrome-remote-desktop.service is masked.

The matter is clear so far: the Chrome Remote Desktop service is masked, so it cannot be started or restarted, as it does not work. If I query the status of the service:

systemctl status chrome-remote-desktop

It also says that it is inactive because it is masked:

● chrome-remote-desktop.service
   Loaded: masked (Reason: Unit chrome-remote-desktop.service is masked.)
   Active: inactive (dead)

In such cases, I cannot even reach the affected computer, which in this case is called "Laptop 1 - Debian10":

It is grayed out as inactive in the list.

So far this would be fine, because normally another service instance is running the appropriate session on behalf of the appropriate user, but the main service needs to be restarted if we modify the above mentioned file for the new settings to take effect in the remote control program.

So the error starts here, that I run the systemctl unmask command, in this case it is ineffective. So the command cannot be used to unlock the service.

We will look at the solution for this in the next chapter.

The solution

When the appropriate commands cannot unlock the masked services, we can also solve such a problem manually. Naturally rootLet's carry out the other parts as well. Let's enter the /lib/systemd/system directory:

cd /lib/systemd/system

Let's search for the name of the service in question here. In my example, I search for the word "chrome":

Here we find the unit files related to the service, as they are / Dev / null symbolic links to . In this example, there is only one such unit file, but in the case of other services there may be several. Furthermore, there is also a file with the ending "@.service", which we will get to in a moment. These /dev/null/ symbolic links pointing to are deleted unlink command:

unlink chrome-remote-desktop.service

Of course, we delete the files of our own service, which we fail to unlock with the unlink option.

Then enable the service with the command shown above:

systemctl enable chrome-remote-desktop@.service

After enabling the service and any additional service instances, let's start it and then check:

systemctl start chrome-remote-desktop.service
systemctl status chrome-remote-desktop.service

So here you can see the main service itself as it runs.

Also, as an interesting point, we can also look at the mentioned instantiated service, which in this case is the child service connected to my own user: 

systemctl status chrome-remote-desktop@botond.service

● chrome-remote-desktop@botond.service - Chrome Remote Desktop instance for botond
   Loaded: loaded (/lib/systemd/system/chrome-remote-desktop@.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2022-08-16 02:47:52 CEST; 1h 49min ago
 Main PID: 1387 (chrome-remote-d)
    Tasks: 0 (limit: 4052)
   Memory: 308.0K
   CGroup: /system.slice/system-chrome\x2dremote\x2ddesktop.slice/chrome-remote-desktop@botond.service
           ‣ 1387 /usr/bin/python3 /opt/google/chrome-remote-desktop/chrome-remote-desktop --child-process --config=/home/botond/.conf

aug 16 02:47:52 laptop systemd[1]: Stopped Chrome Remote Desktop instance for botond.
aug 16 02:47:52 laptop systemd[1]: Started Chrome Remote Desktop instance for botond.
aug 16 02:47:52 laptop systemd[1387]: pam_unix(chrome-remote-desktop:session): session opened for user botond by (uid=0)

(the running times differ here, because I made the description in several details, and in the process I stopped and restarted the machine several times)

Check results

Finally, we can check the result of our work:

The Laptop is available again as it was before the PC update. And the connection also works:

So the remote control also works flawlessly.

After the next reboot of the machine, the main service will be masked or disabled again by the program, but this is part of the normal operation of the remote control program. It won't be a problem again later because the configuration file doesn't need to be changed and the instantiated service will still be running, managing the session associated with the user, ensuring that the according to configuration settings connect the remote control program to the graphical session of the user.

Conclusion

In my own example, this is a rare occurrence, but it happens when the Chrome Remote Desktop package is updated and the configuration file is also affected by the update, in which case I reset my own changes to the file, then manually unmask the service and re-enable it. After that, the program works again without interruption for a long time.

Of course, this was a specific, unique example of manually unlocking a masked service, but it is excellent for demonstrating the process. We can also proceed in a similar way in the case of other services, if the unmask option of the systemctl command for this purpose does not cope with the task for some reason.