Почему некоторые systemd сервисы в состоянии “маскированном”?
Когда я выполняю команду sudo systemctl list-unit-files (Я думаю, что sudo является дополнительным), я произвожусь, который показывает все сервисы и их состояние.
Вот отрывок от моей машины:
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
...
Интересно, почему некоторые сервисы находятся в состоянии "маскированном". Я думаю, что это означает, "это лучше, чем 'отключение', потому что сервис не может быть запущен, ни один вручную или systemd".
Как я могу получить больше информации о состоянии сервисной единицы?
Кто поместил единицы в их соответствующее состояние?
Я попробовал, например, sudo systemctl help dsmcad - то единственное поднимает documentation = ... строка из файла единицы. /etc/systemd/system/dsmcad.service
Примечание: Здесь я знаю точно, что dsmcad сервис и что он делает, я установил его сам. Я больше интересуюсь общим решением.
4 ответа
mask более сильная версия disable. Используя disable удалены все символьные ссылки указанного файла единицы. При использовании mask единицы будут связаны с /dev/null. Это будет отображено, если Вы проверите, например, systemctl status halt.service. Преимущество mask состоит в том, чтобы предотвратить любой вид активации, даже руководство.
Осторожность: systemctl list-unit-files перечисляет состояние единицы файлы (статичный, включенный, отключенный, замаскированный, косвенный) и не имеет никакого отношения к состоянию сервиса. Взглянуть на эти сервисы использование systemctl list-units.
hostname.service маскируется как избыточный потому что systemd наборы имя хоста (от/etc/hostname) очень вначале во время запуска.
Эта установка обеспечивается пакетом Debian systemd.
$ 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
Точно так же Debian может теперь работать без сценария оболочки к halt система, он обрабатывается systemd-завершение-работы (исходный код здесь ) вместо этого.
, Если сервис был замаскирован вручную, маска будет установлена в /etc/systemd/system вместо этого.
Сервисы также маскируются, когда они удалены на Debian/Ubuntu. Я не знаю почему.
Так как Вы запрашиваете информацию о состоянии маскированном, важно упомянуть, что можно заметить в сервисе, что, после того, как запущено, имел его измененные определения, перезагрузка (systemctl перезагрузка демона) и , новое состояние не в порядке . Одним легким примером для понимания этого является следующий сценарий:
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
Следовательно, состояние маскированное может быть порождено из неподходящего сервиса определения. Поэтому пользователь может вызвать размаскированное состояние путем редактирования неправильно сервиса.
Наблюдение: я не уверен, происходит ли это нарочно, или это - простая ошибка (опция по умолчанию), но это может быть некоторая интересная информация для совместного использования
«маска» - это состояние юнит-файлов, которое считается «третьим уровнем выключения» (stop-1st, disable-2nd, mask-3rd). Службы, помеченные как замаскированные, не могут быть запущены ни вручную (с помощью команды запуска), ни с помощью системы (при загрузке системы). Поэтому соблюдайте осторожность при использовании команды маски systemctl на услуга.