Дорогой дневник, мне не подобрать слов, чтобы описать ту боль и унижение, которые я испытал, пытаясь отладить собственный systemd unit.
Всю историю своих побед и провалов я, пожалуй, опишу в одной и следующих статей, тут это будет лишним. А сейчас хочу поделиться несколькими трюками в отладке systemd.
Итак, начнем:
Каждый, кто хоть раз на своем веку печатал в консоли systemctl, знает про команды start/stop/restart/reload для изменения состояния юнита, и enable/disable/mask для изменения его поведения при загрузке системы.
Давайте ради примера посмотрим на нашего демона nginx.
systemctl status nginx
Когда мы создавали собственного демона, мы помещали свой service файл в папку /etc/systemd/system. Однако, демона nginx мы там не найдем. Смотрим внимательно в описание сервиса и видим:
loaded: /lib/systemd/system/nginx.service
Просмотр systemd daemon.
Итак, я хочу посмотреть на конфигурацию этого демона. Логично вывести на экран содержимое файла:
cat /lib/systemd/system/nginx.service
Однако, systemd позволяет использовать свой функционал для просмотра и редактирования сервисов:
systemctl cat nginx
Вывод команды будет точно таким же, за исключением того, что первой строкой будет указан файл, к которому systemd обратился.
Редактирование systemd daemon.
А что, если я хочу изменить параметры указанного демона? Да еще и так, чтобы ничего случайно не поломать. Для такой задачи есть команда edit.
systemctl edit nginx
Откроется редактор, который в первой же строке предупредит нас, что мы редактируем не оригинальный файл, а прокладку, которая переопределит параметры основного юнита:
Editing /etc/systemd/system/nginx.service.d/override.conf
А если я хочу править именно корневой, оригинальный файл демона?
systemctl edit --full nginx
Но и тут все не так просто. В данном случае systemd:
- Копирует оригинальный юнит-файл из /lib/systemd/system/nginx.service в /etc/systemd/system/nginx.service
- Открывает его в редакторе
- После сохранения будет использовать именно эту копию, которую мы создали в /etc/systemd/
Восстановление systemd daemon.
Не ошибается только тот, кто ничего не делает, так ведь? Каждый из нас хоть раз в жизни (а на деле - достаточно регулярно) что-то ломал.
Предположим, и мы отредактировали демона так, что проще все сжечь и переписать с нуля. Для этого существует команда revert.
systemctl revert nginx
Эта команда отменяет все локальные изменения юнита nginx и возвращает его к состоянию по умолчанию, заданному в оригинальных unit-файлах.
Команда удаляет override-файлы в /etc/systemd/system/nginx.service.d/ и /etc/systemd/system/nginx.service и указывает systemd использовать оригинальный файл из /lib/systemd/system/nginx.service
Анализ systemd daemon.
А вот теперь поглубже поговорим о моей личной боли, из-за которой мне пришлось залезать туда, куда я вообще не планировал. А именно в systemd-analyze.
Итак, предположим, у нас происходит какая-то магия с тем, что наша система слишком долго грузится. Надо разбираться в таймингах запуска демонов.
systemd-analyze blame
В выводе получаем список всех демонов и время их запуска.
Если вдруг мы увидим какого-то демона, который будет слишком долго загружаться, не нужно делать поспешные выводы.
Напомню: все systemd сервисы зависят друг от друга, и запускаются в определенном порядке, который указан в них самих же.
Например, у нас postfix@-.service загружался 1.338s.
Проверим, что у него внутри:
systemctl cat postfix@-.service
Тут мы видим, что демон запустится только тогда, когда сеть перейдет в режим онлайн и отработает nss-lookup.
Хотите более подробный вывод?
systemd-analyze critical-chain postfix@-.service
Тут мы уже подробно можем увидеть всю цепочку с самого начала и все зависимости.
Не думаю, что вам часто придется этим пользоваться, но лично мне пару раз это спасло очень много нервных клеток при отладке поведения очередной системы.