Linux unit is masked

Замаскированные службы Linux.

Вы когда-нибудь получали сообщение о невозможности запустить какой-либо сервис, следующего содержания:

Службу вы установили, и уверены, что она работает правильно, но каким-то образом вы больше не можете контролировать ее. Вы никак не можете этим управлять. Так что же случилось?

Скорее всего, кто-то замаскировал вашу службу. Маски — это один из способов отключения службы. В случае, когда вы отключаете службу с помощью sudo systemctl disabled , все символические ссылки для службы удаляются. При маскировании службы символические ссылки перемещаются и указывают на /dev/null. Когда вы просто отключаете службу, ее все равно можно запустить вручную командой start. Когда вы маскируете службу, ее нельзя запустить вручную. Другими словами, маскирование службы делает ее непригодной для использования до тех пор, пока она не будет демаскирована.

Это можно использовать для безопасного отключения службы. Например, вы устанавливаете программное обеспечения с сервисом systemd и обнаруживаете, что в сервисе есть уязвимость. Но вы не хотите удалять приложение, и чтобы оно работало, пока уязвимость не будет устранена, тоже не нужно. В этом случае вы можете замаскировать службу, дождаться исправления уязвимости, обновить программное обеспечение и размаскировать службу.

Иногда служба может быть замаскирована при установке другого программного обеспечения. Чтобы узнать замаскирован ли сервис, вы можете использовать такую ​​команду:

Выполните приведенную выше команду, и вы, вероятно, удивитесь, сколько служб замаскировано в вашей системе. Я обнаружил пару замаскированных сервиса в своей системе, одним из которых был mysql.service. Если я хочу использовать MySQL на этой машине, мне придется сначала размаскировать службу.

Как замаскировать службу в Linux.

Первое, что мы сделаем, это научимся маскировать службу в Linux. Возьмем к примеру службу MySQL. Откройте окно терминала и замаскируйте службу MySQL с помощью команды:

Если вы не маскировали службу MySQL до этого, теперь она будет отображаться в выводе команды systemctl list-unit-files | grep masked. На данный момент служба MySQL не может запускаться ни автоматически, ни вручную. Попробуйте запустить службу командой:

Вы должны будете увидеть следующую ошибку:

Как размаскировать службу в Linux.

Теперь, когда вы замаскировали службу, разберем как все вернуть обратно. Команда будет такой:

Теперь, когда вы запустите MySQL, он будет работать, как обычно.

Вот и все, что вам нужно знать для управления замаскированными службами в Linux. Надеюсь кому-то пригодится.

А если Вам понравилась статья, то подписывайтесь на мой канал дзен (кнопка ниже), либо в telegramm и ВКонтакте . Так же не забудьте про мой сайт RoadIT , в котором я потихоньку собираю материал, знание которого приведет вас в мир IT.

Источник

systemd service unit incorrectly reported as masked

This document (7022685) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 12 Service Pack 1 (SLES 12 SP1)
SUSE Linux Enterprise Server 12 Service Pack 2 (SLES 12 SP2)
SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)

Situation

Checking the status of a service shows it is masked.

Running systemctl unmask doesn’t change the status.

Resolution

The systemd unit file is empty. Replace it in /usr/lib/systemd/system by reinstalling the package in which the unit file was contained.

Reload the systemd configuration file with systemctl daemon-reload after the unit file is replaced.

Cause

Additional Information

Masking a systemd unit is used to prevent the unit from starting.

When a mask is set on a unit, a symbolic link with the name of that unit is created in the /etc/systemd/system directory which points to /dev/null .

Systemd unit files in /etc/systemd/system override vendor-supplied unit files in /usr/lib/systemd/system , so attempting to start a masked unit will do nothing.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.

• Document ID:7022685
• Creation Date: 23-Feb-2018
• Modified Date:03-Mar-2020
• • SUSE Linux Enterprise Server

  For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

  Источник

  systemctl, how to unmask

  I tried systemctl unmask x11-common and systemctl unmask x11-common.service but that did not change anything. How do I unmask it?

  4 Answers 4

  The commands you are using are both correct. See also the manual.

  It seems the unmask command fails when there is no existing unit file in the system other than the symlink to /dev/null . If you mask a service, then that creates a new symlink to /dev/null in /etc/systemd/system where systemd looks for unit files to load at boot. In this case, there is no real unit file.

  x11-common.service was also masked on my system. You can fix it like this:

  First check that the unit file is a symlink to /dev/null

  file /lib/systemd/system/x11-common.service 

  /lib/systemd/system/x11-common.service: symbolic link to /dev/null 

  sudo rm /lib/systemd/system/x11-common.service 

  Since you changed a unit file, you need to run this:

  sudo systemctl daemon-reload 

  systemctl status x11-common 

  if it doesn’t say loaded and running (if the circle is still red), reinstall the package:

  sudo apt-get install --reinstall x11-common 

  and reload the daemon again

  sudo systemctl daemon-reload 

  and check status once more

  systemctl status x11-common 

  Now it’s green and running 🙂 The service has no systemd unit file, but systemd happily uses the script for it in /etc/init.d instead.

  Ok, follow-up question: If it was even masked on your system, what is this service for? It seems as it is not really needed if it is masked for both of us.

  @Albert [See here.]( askubuntu.com/questions/712276/…) seems the service works without the systemd unit file (it has a file in /etc/init/ . ). You might want to ask a new question. What I did made no apparent difference, only the service shows as loaded, enabled, stopped (it’s active on startup) (green) instead of loaded masked dead (red). I should read my logs.

  if an update for systemd comes by, the unit file is reinstalled, so this isn’t really a structural solution

  @hbogert does that happen even if there was no unit file apart from the symlink to /dev/null ? You are right about my answer though. I would call this solution a workaround for a. confusing behaviour. of systemd

  Could you describe your first sentence in terms of exact files which matter in this case (because I don’t really understand the scenario your describing)?

  systemctl edit systemd-hostnamed Add the 2 lines below then exit the editor (don’t forget to save when prompted):

  /etc/systemd/system/systemd-hostnamed.service.d/ 

  systemctl restart systemd-hostnamed 

  You should now be able to run hostnamectl without it hanging.

  Here I show how I remove the mask using systemctl

  $ sudo systemctl status bluetooth.service ● bluetooth.service Loaded: masked (Reason: Unit bluetooth.service is masked.) Active: inactive (dead) $ sudo systemctl unmask bluetooth.service Removed /etc/systemd/system/bluetooth.service. $ sudo systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: e> Active: inactive (dead) Docs: man:bluetoothd(8) $ sudo systemctl start bluetooth.service $ sudo systemctl status bluetooth.service ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: e> Active: active (running) since Sat 2022-07-30 08:50:04 +06; 2s ago Docs: man:bluetoothd(8) Main PID: 23191 (bluetoothd) Status: "Running" Tasks: 1 (limit: 9135) Memory: 1.6M CGroup: /system.slice/bluetooth.service └─23191 /usr/lib/bluetooth/bluetoothd 

  Источник