Вопрос или проблема
Список отсутствующих сервисов
systemctl --state=not-found --all
Вывод:
UNIT LOAD ACTIVE SUB DESCRIPTION
● boot.automount not-found inactive dead boot.automount
● home.mount not-found inactive dead home.mount
● tmp.mount not-found inactive dead tmp.mount
● connman.service not-found inactive dead connman.service
● console-screen.service not-found inactive dead console-screen.service
● dpdk.service not-found inactive dead dpdk.service
● fcoe.service not-found inactive dead fcoe.service
● firewalld.service not-found inactive dead firewalld.service
● haveged.service not-found inactive dead haveged.service
● ip6tables.service not-found inactive dead ip6tables.service
● iptables.service not-found inactive dead iptables.service
● iscsi-shutdown.service not-found inactive dead iscsi-shutdown.service
● iscsi.service not-found inactive dead iscsi.service
● iscsid.service not-found inactive dead iscsid.service
● kbd.service not-found inactive dead kbd.service
● rbdmap.service not-found inactive dead rbdmap.service
● systemd-hwdb-update.service not-found inactive dead systemd-hwdb-update.service
● systemd-oomd.service not-found inactive dead systemd-oomd.service
● systemd-update-done.service not-found inactive dead systemd-update-done.service
● systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service
● xencommons.service not-found inactive dead xencommons.service
● xendomains.service not-found inactive dead xendomains.service
● virtlxcd.socket not-found inactive dead virtlxcd.socket
● virtqemud.socket not-found inactive dead virtqemud.socket
● virtvboxd.socket not-found inactive dead virtvboxd.socket
● virtvzd.socket not-found inactive dead virtvzd.socket
● virtxend.socket not-found inactive dead virtxend.socket
Найти юниты, которые ссылаются на отсутствующие сервисы
grep -rR "<service_name>" /usr/lib/systemd
grep -rR "<service_name>" /etc/systemd
# Ознакомьтесь с таблицами на странице руководства для получения информации о других директориях для поиска с помощью grep и об их назначении
man systemd.unit
Пример для tmp.mount
grep -rR "tmp.mount" /usr/lib/systemd
grep -rR "tmp.mount" /etc/systemd
Вывод:
/usr/lib/systemd/system/basic.target:After=sysinit.target sockets.target paths.target slices.target tmp.mount
/usr/lib/systemd/system/basic.target:Wants=tmp.mount
Очистить ссылки
sudo nano /usr/lib/systemd/system/basic.target
Содержимое:
[Unit]
Description=Basic System
Documentation=man:systemd.special(7)
Requires=sysinit.target
Wants=sockets.target timers.target paths.target slices.target
After=sysinit.target sockets.target paths.target slices.target tmp.mount
RequiresMountsFor=/var /var/tmp
Wants=tmp.mount
Здесь мы нашли tmp.mount
под After=
и Wants=
Я хочу удалить эти записи, чтобы systemctl --state=not-found --all
больше их не отображал, и так для каждого отсутствующего юнита.
Вопрос
Безопасно ли удалять такие записи для каждого отсутствующего юнита в системе?
Безопасно ли очищать (удалять) ссылки на отсутствующие юниты systemd?
Нет. Вы можете понять, что они там находятся на случай, если в какой-то момент какой-то сервис действительно будет внедрён.
Удаляя их, вы достигаете:
- нагрузки
- снижения надёжности в условиях изменений среды
- потенциальных ошибок, приводящих к нарушению работы системы
- больше работы в будущем, так как каждое обновление системных сервисов может теперь потребовать от вас решения, хотите ли вы сохранить свою изменённую версию файлов сервисов, или же автоматически не обновлять файл, что приводит снова к
- снижению надёжности при обновлении
вы не достигаете:
- никакого ускорения
- снижения вероятности ошибок / уязвимости безопасности
Я хочу удалить эти записи, чтобы systemctl –state=not-found –all больше их не отображал, и так для каждого отсутствующего юнита.
Но зачем? Они не «стоят» ничего, они не создают проблем, более того, они предназначены для поддержки в таком виде.
Так что оставьте их в покое.
Здесь мы нашли tmp.mount под After= и Wants=
И это будет вашей первой серьёзной ошибкой. То, что tmp.mount
не найден, не означает, что его указание не важно. Это не обычный файл сервиса, а юнит монтирования… так что, в самом деле, оставьте это в покое.
.
Ответ или решение
Удаление ссылок на отсутствующие системные юниты systemd является частым вопросом для администраторов систем, которые хотят упростить управление и поддержание системы в актуальном состоянии. Однако, несмотря на очевидную пользу в виде сокращения списка неактивных сервисов, стоит задуматься о последствиях таких действий.
Теоретическая часть
Теория: systemd — это системный инициализатор, использующий юниты для управления службами, точками монтирования и другими системными компонентами. Отсутствие юнитов само по себе не является ошибкой; это указывает только на то, что в данный момент они не установлены или не активны. Ссылки на отсутствующие юниты могут оставаться в конфигурационных файлах, например, если они необходимы для будущей инсталляции соответствующих сервисов или для поддержания зависимости между юнитами.
Риски удаления ссылок на отсутствующие юниты:
- Нарушение зависимостей: Некоторые сервисы могут требовать эти юниты для корректной работы в будущем. Удаление ссылок может нарушить корректность их активации.
- Неожиданное поведение системы: При обновлении или изменении конфигурации системы могут возникнуть ошибки, так как наличествовавшие зависимости больше не будут удовлетворены.
- Усложнение администрирования: При необходимости повторной установки сервисов может потребоваться восстановление удаленных конфигураций, что увеличивает трудозатраты.
Пример ситуации
Допустим, у вас есть система, где некоторые из юнитов, такие как tmp.mount
, указаны в списке отсутствующих. Эти юниты могут быть частью стандартной конфигурации некоторых дистрибутивов Linux, которые в определенных ситуациях используют tmp.mount
для монтирования временных файловых систем. Хотя сейчас они и не активны, в будущем могут понадобиться изменения в конфигурации, требующие создания и монтирования временного раздела.
Аналогично, юниты, такие как firewalld.service
или iscsi.service
, могут отсутствовать только по причине текущих настроек безопасности или архитектуры системы. В случае изменения политики безопасности эти юниты могут быть востребованы, и их отсутствие может вызвать сбои в работе системы.
Применение
Что делать и чего не делать:
- Не удаляйте ссылки на отсутствующие юниты без критического анализа: Казалось бы, безобидное удаление может привести к большим проблемам в дальнейшем.
- Документируйте изменения: Если вы решили изменить конфигурации, обязательно документируйте все действия. Это поможет вам или вашему преемнику понять логику этих изменений в будущем.
- Используйте комментарии: Вместо удаления, рассмотрите возможность комментирования строк, которые вызывают тревогу. Это оставит вам возможность легко вернуть изменения обратно.
- Проверяйте зависимости: Используйте системные команды такие как
systemctl list-dependencies
, чтобы убедиться, что ваши изменения не окажут негативного влияния на важные системные службы.
Заключение
Подводя итог, безопаснее всего оставить ссылки на отсутствующие юниты в системе, поскольку они не создают дополнительной нагрузки и могут оказаться полезными в будущем. Это может показаться противоположным интуитивному стремлению "очистить" список сервисов, однако необходимо помнить, что эти юниты потенциально поддерживают устойчивость и гибкость вашей системы в условиях меняющихся требований.