9.10. Настройка и использование Systemd

9.10.1. Базовая настройка

Файл /etc/systemd/system.conf содержит параметры для управления основными операциями systemd. Изначально все записи в этом файле закомментированы с указанием настроек по умолчанию. В этом файле может быть изменен уровень логирования, а также некоторые базовые настройки ведения файлов логов. Смотрите страницу руководства systemd-system.conf(5) для получения подробной информации по каждому параметру.

9.10.2. Отключение очистки экрана во время загрузки

Обычным поведением systemd является очистка экрана по окончании загрузки. При желании такое поведение можно изменить, выполнив следующую команду:

mkdir -pv /etc/systemd/system/getty@tty1.service.d

cat > /etc/systemd/system/getty@tty1.service.d/noclear.conf << EOF
[Service]
TTYVTDisallocate=no
EOF

Сообщения, отображаемые при загрузке всегда можно просмотреть, выполнив команду journalctl -b от имени пользователя root.

9.10.3. Отключение tmpfs для /tmp

По умолчанию каталог /tmp монтируется как tmpfs. Если такое поведение нежелательно, его можно переопределить, выполнив следующую команду:

ln -sfv /dev/null /etc/systemd/system/tmp.mount

В качестве альтернативы, если требуется отдельный раздел для /tmp укажите его в /etc/fstab.

[Предупреждение]

Предупреждение

Не создавайте символическую ссылку, указанную выше, если используется отдельный раздел для /tmp. Это помешает монтированию корневой файловой системы (/) в режиме r/w и сделает систему непригодной для загрузки.

9.10.4. Настройка автоматического создания и удаления временных файлов

Существует несколько служб, которые создают или удаляют файлы или каталоги:

  • systemd-tmpfiles-clean.service

  • systemd-tmpfiles-setup-dev.service

  • systemd-tmpfiles-setup.service

Системные файлы конфигурации расположены в /usr/lib/tmpfiles.d/*.conf. Локальные конфигурационные файлы находятся в /etc/tmpfiles.d. Файлы в /etc/tmpfiles.d переопределяют файлы с таким же именем в /usr/lib/tmpfiles.d. Смотрите подробности по формату файла в руководстве tmpfiles.d(5).

Обратите внимание, что синтаксис файлов в /usr/lib/tmpfiles.d/*.conf может сбивать с толку. Например, по умолчанию, удаление файлов в каталоге /tmp находится в файле /usr/lib/tmpfiles.d/tmp.conf в строке:

q /tmp 1777 root root 10d

q, в поле type, указывает что необходимо создать подраздел с квотами, что применимо только к файловым системам btrfs. Он ссылается на type v который, в свою очередь, ссылается на type d (каталог). Затем создается указанный каталог, если он отсутствует, и настраиваются разрешения и владелец. Содержимое каталога будет очищаться через указанный интервал времени, если указан аргумент age.

Если параметры по умолчанию не нужны, файл следует скопировать в /etc/tmpfiles.d и отредактировать по желанию. Например:

mkdir -p /etc/tmpfiles.d
cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d

9.10.5. Переопределение поведения служб по умолчанию

Параметры юнита можно переопределить, создав каталог и файл конфигурации в /etc/systemd/system. Пример для условного юнита foobar:

mkdir -pv /etc/systemd/system/foobar.service.d

cat > /etc/systemd/system/foobar.service.d/foobar.conf << EOF
[Service]
Restart=always
RestartSec=30
EOF

Дополнительную информацию смотрите на странице руководства systemd.unit(5). После создания файла конфигурации запустите systemctl daemon-reload и systemctl restart foobar, чтобы активировать изменения в службе.

9.10.6. Отладка порядка загрузки служб

Вместо простых сценариев оболочки, используемых в системах инициализации SysVinit или BSD, systemd использует унифицированный формат для различных типов запускаемых файлов (или юнитов). Команда systemctl используется для запуска, остановки, управления состоянием и получения статуса юнит-файлов. Ниже несколько примеров часто используемых команд:

  • systemctl list-units -t <service> [--all]: выводит список загруженных юнит-файлов типа service.

  • systemctl list-units -t <target> [--all]: выводит список загруженных юнит-файлов типа target.

  • systemctl show -p Wants <multi-user.target>: показывает все юнит-файлы, зависящие от multi-user target (многопользовательского режима). Target - специальные юнит-файлы, которые аналогичны уровням запуска в SysVinit.

  • systemctl status <servicename.service>: показывает статус службы servicename. Расширение .service можно опустить, если нет других юнит-файлов с таким же именем, например, .socket (которые создают прослушивающий сокет, обеспечивающий функции аналогичные inetd/xinetd).

9.10.7. Работа с журналом Systemd

Вход в систему, загруженную с помощью systemd, обрабатывается с помощью systemd-journald (по умолчанию), а не классическим демоном системного журнала unix. При желании, вы можете добавить обычный демон системного журнала и заставить их работать бок о бок. Программа systemd-journald сохраняет записи журнала в двоичном формате, а не в обычном текстовом. Для разбора лога предоставляется команда journalctl. Ниже несколько примеров часто используемых команд:

  • journalctl -r: показывает все содержимое журнала в обратном хронологическом порядке.

  • journalctl -u UNIT: показывает записи журнала, связанные с указанным юнит-файлом.

  • journalctl -b[=ID] -r: показывает записи журнала с момента последней успешной загрузки (или для идентификатора загрузки) в обратном порядке хронологический порядке.

  • journalctl -f: предоставляет функциональность, аналогичную tail -f (режим следования).

9.10.8. Работа с дампами ядра

Дампы ядра полезны для отладки аварийно завершившихся программ, особенно, когда происходит сбой процесса демона. В системах с systemd дампы ядра обрабатывается командой systemd-coredump. Команда запишет дамп в журнал и сохранит сам дамп ядра в /var/lib/systemd/coredump. Чтобы получить и обработать дамп, предоставляется инструмент coredumpctl. Несколько примеров часто используемых команд:

  • coredumpctl -r: выводит список всех дампов в обратном хронологическом порядке.

  • coredumpctl -1 info: отображает информацию из последнего дампа ядра.

  • coredumpctl -1 debug: загружает последний дамп ядра в GDB.

Дампы ядра могут занимать много места на диске. Можно ограничить место на диске, занимаемое дампами ядра, создав конфигурационный файл в /etc/systemd/coredump.conf.d. Например:

mkdir -pv /etc/systemd/coredump.conf.d

cat > /etc/systemd/coredump.conf.d/maxuse.conf << EOF
[Coredump]
MaxUse=5G
EOF

Смотрите следующие страницы руководства для получения дополнительной информации информация systemd-coredump(8), coredumpctl(1) и coredump.conf.d(5).

9.10.9. Длительно выполняющиеся процессы

Начиная с версии systemd-230, все пользовательские процессы завершаются, когда завершается пользовательская сессия, даже если используется nohup или процесс использует функции daemon() или setsid().Это намеренный переход от исторически разрешительной среды к более ограничительной. Нововведение может вызвать проблемы, если вы применяете долго работающие программы (такие как, screen или tmux), чтобы оставаться активным после завершения вашей пользовательской сессии. Есть три способа разрешить процессам работать после того, как сеанс пользователя завершен.

  • Включить долгосрочные процессы для выбранных пользователей: Обычные пользователи имеют разрешение на включение долгосрочных процессов с помощью команды loginctl enable-linger для самих себя. Системные администраторы могут использовать ту же команду с аргументом user для включения lingering'а пользователю. После этого пользователь может использовать команду systemd-run, чтобы запустить длительный процесс. Например: systemd-run --scope --user /usr/bin/screen. Если вы разрешите выполнение долгосрочных процессов пользователю, то user@.service останется даже после завершения всех сеансов входа в систему и автоматически запустится при загрузке системы. Это является преимуществом, потому что явно разрешает и запрещает запуск процессов после завершения сеанса пользователя, но нарушает обратную совместимость с такими инструментами, как nohup и утилитами, которые используют daemon().

  • Включить долгосрочные процессы в системе(глобально): Вы можете установить KillUserProcesses=no в /etc/systemd/logind.conf для включения долгосрочных процессов глобально для всех пользователей. Преимуществом этого метода является то, что вы оставляете старый метод доступным всем пользователям за счет явного контроля.

  • Отключить во время сборки: вы можете запретить завершение процессов при сборке systemd, добавив ключ -D default-kill-user-processes=false в команде meson для systemd. Это полностью отключает возможность systemd убивать пользовательские процессы в конце сеанса.