Когда я выполняю команду sudo systemctl list-unit-files (Я думаю, что sudo является необязательным), я получаю вывод, который показывает все службы и их состояние.
Вот фрагмент из моей машины:
UNIT FILE STATE...debian-fixup.service static debug-shell.service disableddisplay-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 indirectgpsdctl@.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 и что она делает, я установил ее сам. Меня больше интересует общее решение.
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.servicelrwxrwxrwx 1 root root 9 Apr 8 22:47 /lib/systemd/system/hostname.service -> /dev/null$ dpkg-query --search /lib/systemd/system/hostname.servicesystemd: /lib/systemd/system/hostname.service
Аналогичным образом, Debian теперь может запускаться без сценария оболочки для halt система, она обрабатывается systemd-завершение работы (исходный код здесь) вместо этого.
Если служба была замаскирована вручную, маска будет установлена в /etc/systemd/system вместо.
Службы также маскируются, когда они удаляются в Debian/Ubuntu. Я не знаю почему.
Поскольку вы запрашиваете информацию о замаскированном состоянии, важно отметить, что его можно наблюдать в службе, которая после запуска изменила свои определения, перезагрузила (systemctl daemon-reload) и новое состояние НЕ в порядке. Одним из простых примеров для понимания этого является следующий сценарий:
a) the service is running well (already started)b) edit the service definition file and delete everything in its contentsc) reloadd) state masked will be observed too
Следовательно, замаскированное состояние может быть вызвано неправильным определением службы.Следовательно, пользователь может вызвать состояние без маски, неправильно отредактировав сервис.
Замечание: Я не уверен, происходит ли это специально или это простая ошибка (опция по умолчанию), но это может быть интересной информацией для обмена
"маска" - это состояние единичных файлов, которое рассматривается как "третий уровень отключения" (остановка-1-й, отключение-2-й, маска-3-й). Службы, помеченные как замаскированные, не могут быть запущены ни вручную (с помощью команды start), ни системами (при загрузке системы). Поэтому будьте осторожны при использовании команды systemctl mask в службе.