Jak wyłączyć systemowe zachowanie agresywnej powłoki awaryjnej?

Domyślnie systemd spada do powłoki awaryjnej przy najmniejszym błędzie. Na przykład, jeśli jeden z montowań w fstab z jakiegoś powodu zawiedzie, system natychmiast przestanie się uruchamiać. Zarządzam dziesiątkami różnych systemów produkcyjnych i uważam to zachowanie za bardzo szkodliwe. (Właściwie myślę, że to poważna porażka projektowa, ale to osobista opinia).

Chciałbym zwiększyć odporność systemu na rozruch. Optymalnie system powinien zawsze uruchamiać się, brakujące sterowniki, mocowania itp. Nie powinny upuszczać powłoki awaryjnej (zamiast tego wyświetlać tylko ostrzeżenie), chyba że podany błąd uniemożliwi zalogowanie się do konsoli. Co można uruchomić, należy uruchomić.

Wiem, że systemd automatycznie generuje pliki * .mount z / etc / fstab i mogłem użyć opcji nofail z małym limitem czasu x-systemd.device (lub sam zdefiniować odpowiednie pliki .mount). Jednak nie rozwiązałoby to mojego problemu, chcę, aby system był bardziej odporny, „łatanie” fstab za każdym razem nie jest zbyt wygodne i nie jestem pewien, ile istnieje innych możliwych „problemów”, które uniemożliwiłyby uruchomienie systemu tylko dlatego, że jakiś programista uważał, że jest to wystarczająco ważne.

W pewnym sensie chciałbym odzyskać kontrolę nad moją maszyną i nie pozwalać systemdowi decydować, który problem jest wystarczająco poważny, aby zniszczyć proces uruchamiania. Czy to możliwe?

To dosłownie tylko awarie montowania, to wszystko, co musisz zmienić.

Tak więc odpowiedź na list byłaby trywialna. Utwórz plik rozwijany:

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

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

Wierzę, że nie doda to żadnego nowego problemu, poza tymi, których już doświadczył Linux sysvinit, dopuszczając ten scenariusz częściowej awarii.

Wskazałeś jednak również na pytanie, jak długo systemd powinien czekać na dostępność określonych urządzeń blokowych. Nie widzę żadnego sposobu, aby to skonfigurować bez zapewnienia zamiennika dla generatora fstab jako całości. https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Jeśli zrzucisz tutaj dużą ilość rzadziej używanego kodu, wydaje się mało prawdopodobne, aby zwiększyć odporność systemu. Myślę, że najbliższym rozwiązaniem byłoby załatanie istniejącego generatora fstab. Nie jest to bardzo skomplikowane, podejrzewam, że można to zrobić / nadążyć za wszelkimi znaczącymi zmianami.

Technicznie rzecz biorąc, jeśli twoja dystrybucja zawiera samodzielny mountallskrypt sysvinit, możesz spróbować go podłączyć. Ale to znacznie zmieni proces uruchamiania - to właściwie bardziej rozwidlenie. Nie poleciłbym tego podejścia.

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

Jeśli przeszukujesz pliki jednostek, istnieje tylko kilka sposobów powrotu do rozruchu emergency.target. Zwykle następuje .mountawaria jednostki dla lokalnego systemu plików, co powoduje local-fs.target awarię. Lub gdy initramfs nie zamontuje głównego systemu plików, jeśli initramfs używa systemd.

local-fs.targetma OnFailure=emergency.target. I to się nie udaje, ponieważ jednostki dla lokalnych systemów plików są automatycznie dodawane do listy Wymaga local-fs.target (chyba że mają DefaultDependencies=no).

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

Wyłącz automatyczne montowanie dowolnego systemu plików, który nie jest niezbędny do uruchomienia systemu, dodając noautoopcję mount do jego /etc/fstabwpisu:

/dev/sdxy /u01 nfs defaults 0 0

do:

/dev/sdyx /u01 nfs noauto 0 0

a następnie zamontuj system plików po uruchomieniu za pomocą linii w /etc/rc.local:

mount /u01

W tym przykładzie zastosowano system plików NFS, ale ma on również zastosowanie do jednostek LUN importowanych z serwera plików.

Może to spróbować?

systemctl mask emergency.service
systemctl mask emergency.target