Как отключить агрессивное поведение оболочки 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.