Безопасно ли очищать (удалять) ссылки на отсутствующие юниты systemd?

Вопрос или проблема

Список отсутствующих сервисов

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 — это системный инициализатор, использующий юниты для управления службами, точками монтирования и другими системными компонентами. Отсутствие юнитов само по себе не является ошибкой; это указывает только на то, что в данный момент они не установлены или не активны. Ссылки на отсутствующие юниты могут оставаться в конфигурационных файлах, например, если они необходимы для будущей инсталляции соответствующих сервисов или для поддержания зависимости между юнитами.

Риски удаления ссылок на отсутствующие юниты:

  1. Нарушение зависимостей: Некоторые сервисы могут требовать эти юниты для корректной работы в будущем. Удаление ссылок может нарушить корректность их активации.
  2. Неожиданное поведение системы: При обновлении или изменении конфигурации системы могут возникнуть ошибки, так как наличествовавшие зависимости больше не будут удовлетворены.
  3. Усложнение администрирования: При необходимости повторной установки сервисов может потребоваться восстановление удаленных конфигураций, что увеличивает трудозатраты.

Пример ситуации

Допустим, у вас есть система, где некоторые из юнитов, такие как tmp.mount, указаны в списке отсутствующих. Эти юниты могут быть частью стандартной конфигурации некоторых дистрибутивов Linux, которые в определенных ситуациях используют tmp.mount для монтирования временных файловых систем. Хотя сейчас они и не активны, в будущем могут понадобиться изменения в конфигурации, требующие создания и монтирования временного раздела.

Аналогично, юниты, такие как firewalld.service или iscsi.service, могут отсутствовать только по причине текущих настроек безопасности или архитектуры системы. В случае изменения политики безопасности эти юниты могут быть востребованы, и их отсутствие может вызвать сбои в работе системы.

Применение

Что делать и чего не делать:

  • Не удаляйте ссылки на отсутствующие юниты без критического анализа: Казалось бы, безобидное удаление может привести к большим проблемам в дальнейшем.
  • Документируйте изменения: Если вы решили изменить конфигурации, обязательно документируйте все действия. Это поможет вам или вашему преемнику понять логику этих изменений в будущем.
  • Используйте комментарии: Вместо удаления, рассмотрите возможность комментирования строк, которые вызывают тревогу. Это оставит вам возможность легко вернуть изменения обратно.
  • Проверяйте зависимости: Используйте системные команды такие как systemctl list-dependencies, чтобы убедиться, что ваши изменения не окажут негативного влияния на важные системные службы.

Заключение

Подводя итог, безопаснее всего оставить ссылки на отсутствующие юниты в системе, поскольку они не создают дополнительной нагрузки и могут оказаться полезными в будущем. Это может показаться противоположным интуитивному стремлению "очистить" список сервисов, однако необходимо помнить, что эти юниты потенциально поддерживают устойчивость и гибкость вашей системы в условиях меняющихся требований.

Оцените материал
Добавить комментарий

Капча загружается...