Вопрос или проблема
Я не очень хорошо знаком с systemd. Ответ, который я ищу в этом вопросе:
Как сделать так, чтобы systemd реагировал на проблемы, “опуская пользователя в аварийную оболочку”, вместо того чтобы просто оставлять систему неотзывчивой?
Пример для объяснения: В случае установки Arch Linux на ThinkPad, кажется, что есть некоторая неправильная конфигурация x-org-server, wayland, возможно, systemd или lightdm, которая вместо того, чтобы выдавать сообщение об ошибке, оставляет пользователя в подвешенном состоянии. Это означает, что пользователь видит, что служебные/запусковые сообщения, выводимые на tty1, останавливаются, без выдачи какого-либо сообщения об ошибке (если есть, это великолепный systemd-journald его съел??) и никакая комбинация клавиш не может даже вызвать root оболочку, чтобы пользователь мог проверить ошибку и исправить её.
Соответственно, ответ, как настроить systemd, чтобы перейти в аварийную оболочку, чтобы избежать зависания системы при любой ошибке, на пути к graphical.target
Как может выглядеть такая ситуация зависания, указано, например, в этом вопросе на U&L “arch-linux-hang-on-reached-target-graphical-interface“
Ни одна часть конфигурации systemd не включает намеренно неотзывчивую систему как путь.
Systemd действительно имеет много конфигураций, посвященных управлению процессами. См., например, Restart= и OnFailure=.
Чтобы решить вашу проблему и избежать неотзывчивой системы, вам нужно лучше понять, что является причиной. Проверка journalctl -xe — хорошее начало (возможно, после перезагрузки). Попробуйте искать “fatal” или “error” в выводе.
Если у вас возникла ошибка ядра или повреждена память, systemd в любом случае не сможет вам помочь.
Цель emergency.target может быть активирована, когда единица переходит в состояние сбоя, с использованием OnFailure=emergency.target в разделе [Unit]. Тем не менее, служба, которая “зависает” (вечно зацикливается), не вызовет состояние сбоя, она будет продолжать работать, пока не будет убита или не будет достигнуто время ожидания.
Systemd не может знать, делает ли программа, которая “зависла”, то, для чего она предназначена, или она терпит неудачу, это должен решать системный администратор.
.
Ответ или решение
Для того чтобы обеспечить перевод системы в аварийный режим вместо зависания, нам необходимо рассмотреть архитектуру Systemd и способы обработки непредвиденных ситуаций. Systemd, будучи замещением устаревших систем инициализации, предоставляет множество инструментов для управления процессами и их отказами.
Теория: управление ошибками в Systemd
Systemd предоставляет возможности для управления поведением сервисов и обработки ошибок. В частности, параметры Restart= и OnFailure= в конфигурационных файлах позволяют задавать условия перезапуска сервисов и реакции на их сбои. Когда сервис завершает работу с ошибкой, Systemd может автоматически пытаться его перезапустить или запускать другие предопределённые действия, например, переход в аварийный режим.
Если вы хотите, чтобы система переводилась в аварийный режим при сбоях, например при неправильно сконфигурированном графическом сервере, вы можете применить параметр OnFailure=emergency.target. Этот параметр указывает systemd переключаться в emergency.target, когда определенные системные юниты завершаются ошибкой.
Пример: применение параметров конфигурации
Предположим, у вас имеется служба, например, LightDM, которая может неправильно работать из-за конфигурации X.org или Wayland. Если LightDM зависает и не переходит в graphical.target, и вы хотите войти в аварийный shell, примените следующие изменения в /etc/systemd/system/lightdm.service или эквивалентном файле:
[Unit]
Description=Light Display Manager
Documentation=man:lightdm(1)
After=systemd-user-sessions.service
Conflicts=getty@tty7.service
After=rc-local.service plymouth-quit-wait.service systemd-user-sessions.service aalib.service graphical.target
OnFailure=emergency.target
[Service]
...Применение: работа с журналами и интерпретация ошибок
Важным шагом является понимание и интерпретация сообщений об ошибках для предотвращения незапланированных отказов. Для получения информации об ошибках в вашем случае полезно будет изучить журналы с помощью journalctl. Команда journalctl -xe предоставит детализированный вывод, где вы можете искать ключевые слова, такие как "error" или "fatal", чтобы лучше понять, где происходит сбой.
Однако, важно помнить, что не все формы зависания могут быть интерпретированы как ошибки systemd. Например, системные службы, застрявшие в цикле или ожидающие ресурсы, могут не активировать аварийные триггеры. В таких случаях необходимо использовать дополнительные механизмы мониторинга и управления, такие как таймауты:
TimeoutStartSec=30
TimeoutStopSec=10Заключение и рекомендации
Обеспечение системы аварийным shell — это мощный метод управления сбоями, который предотвращает полное зависание и позволяет администраторам оперативно решать проблемы. Помимо использования параметра OnFailure=emergency.target, рекомендуется систематически проверять конфигурации служб на предмет ошибок и зависимостей, а также использовать автоматизацию для обнаружения и устранения потенциальных проблем. Используйте регулярное обновление системного ПО и регенерацию конфигураций для поддержки стабильного окружения.