Как отключить агрессивное поведение оболочки systemd?


10

По умолчанию systemd переходит в аварийную оболочку при малейшей ошибке. Например, если по какой-либо причине происходит сбой одного из монтирований на fstab, система сразу же перестает загружаться. Я управляю десятками разнообразных производственных систем и считаю, что это поведение очень пагубно. (На самом деле я думаю, что это серьезный провал проекта, но это личное мнение).

Я бы хотел повысить устойчивость системы к загрузке. Оптимально, чтобы система всегда загружалась, отсутствующие драйверы, монтируемые и т. Д. Не должны сбрасывать аварийную оболочку (вместо этого просто показывать предупреждение), если только данная ошибка не сделает вход в консоль абсолютно невозможным. Что может быть запущено, что должно быть запущено.

Я знаю, что systemd автоматически генерирует файлы * .mount из / etc / fstab, и я мог бы использовать опцию nofail с небольшим таймаутом x-systemd.device (или определить соответствующие файлы .mount самостоятельно). Однако это не решило бы мою проблему, я хочу сделать систему более устойчивой, «исправление» fstab каждый раз не очень удобно, и я не уверен, сколько существует других возможных «проблем», которые делают мою систему не загружаемой только потому, что какой-то разработчик где-то думал, что это достаточно важно.

В своем роде я хотел бы восстановить контроль над моей машиной и не позволить systemd решить, какая проблема является достаточно серьезной, чтобы нарушить процесс загрузки. Является ли это возможным?


в чем собственно проблема? я знаю о двух - невозможности войти через ssh и приглашение sulogin, позволяющее только root, но не пользователям sudo, получать доступ в аварийном режиме. покрывают ли эти убытки, которые вы понесли?
— sourcejedi

На самом деле система была бы гораздо более доступной, если бы эти две службы были запущены, да. Оптимально система должна запускать все, что может быть запущено, как в старые времена SysV (журнал ошибок вместо мучительной смерти от аварийной оболочки), и запускать оболочку только в случае фатальной ошибки.
— goteguru

Ответы:


7

Это буквально только неудачи монтирования, это все, что вам нужно изменить.

Так что письмо с вашей просьбой будет тривиально ответить. Создайте раскрывающийся файл:

# /etc/systemd/system/local-fs.target.d/nofail.conf

# Clear OnFailure= (set it to nothing)
[Unit]
OnFailure=

Я полагаю, что это не добавит новых проблем, кроме тех, которые Linux sysvinit уже перенес, допустив этот сценарий частичного сбоя.


Однако вы также указали вопрос о том, как долго systemd должен ждать, пока указанные блочные устройства станут доступными. Я не вижу способа настроить это, не предоставив замену генератору fstab в целом. https://www.freedesktop.org/software/systemd/man/systemd.generator.html

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

Технически, если в вашем дистрибутиве есть автономный mountallскрипт sysvinit, вы можете попытаться подключить его. Но это значительно изменит процесс загрузки - на самом деле это скорее форк. Я бы не рекомендовал такой подход.


https://unix.stackexchange.com/a/393711/29483

Если вы просматриваете файлы модуля, есть только несколько способов вернуться к загрузке emergency.target. Обычно происходит .mountсбой модуля для локальной файловой системы, что приводит local-fs.target к сбою. Или когда ваш initramfs не может смонтировать корневую файловую систему, если ваш initramfs использует systemd.

local-fs.targetесть OnFailure=emergency.target. И это происходит сбой, потому что модули для локальных файловых систем автоматически добавляются в список Требуется local-fs.target (если они не имеют DefaultDependencies=no).

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

2
Я полагаю, я должен положить [Unit]\nOnFailure= в свой nofail.conf. По-видимому, можно настроить время ожидания в /etc/systemd/system.conf (с помощью общей опции DefaultTimeoutStartSec). Мои системы обычно достаточно быстрые, 90-е годы кажутся излишними. Это решение кажется многообещающим.
— goteguru

В моем случае я ставлю OnFailure=в /lib/systemd/system/local-fs.targetвместо /etc/systemd(Ubuntu 16.04 на AWS)
— ThiagoAlves

@ThiagoAlves вам не следует этого делать, он будет перезаписан при обновлении системы. Следуйте инструкциям в ответе или попросите разъяснений :-).
— Sourcejedi

@sourcejedi Я попробовал ответ, но он не сработал для меня
— ThiagoAlves

1
@ThiagoAlves Спасибо за ваш отзыв. Я сделал ответ менее двусмысленным, поэтому мы можем прояснить, была ли это проблема или нет. Т.е. мне интересно, если ты обязательно включил [Unit]раньше OnFailure=.
— sourcejedi

0

Отключите автоматическое монтирование любой файловой системы, которая не является существенной для операции загрузки, добавив noautoопцию монтирования к ее /etc/fstabзаписи:

/dev/sdxy /u01 nfs defaults 0 0

чтобы:

/dev/sdyx /u01 nfs noauto 0 0

а затем смонтировать файловую систему после загрузки, используя строку в /etc/rc.local:

mount /u01

В этом примере используется NFS, но он также применим к логическим устройствам, импортированным с файлового сервера.


1
Да, я знаю noauto, но если бы я каждый раз менял fstab, nofail был бы намного лучшим выбором. В любом случае, спасибо.
— goteguru

0

Попробуйте это возможно?

systemctl mask emergency.service
systemctl mask emergency.target

4
Вы пробовали это? Что происходит, когда systemd обнаруживает ошибку во время загрузки, когда аварийная цель маскируется?
— Стивен Китт
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.