Wie deaktiviere ich das aggressive System-Shell-Verhalten?


10

Standardmäßig wird systemd beim geringsten Fehler in eine Notfall-Shell verschoben. Wenn beispielsweise eine der Bereitstellungen bei fstab aus irgendeinem Grund fehlschlägt, kann das System sofort nicht mehr gestartet werden. Ich verwalte Dutzende verschiedener Produktionssysteme und habe dieses Verhalten als sehr schädlich empfunden. (Eigentlich denke ich, dass es ein großer Designfehler ist, aber das ist eine persönliche Meinung).

Ich möchte die Ausfallsicherheit des Systemstarts erhöhen. Optimalerweise sollte das System immer hochfahren, fehlende Treiber, Halterungen usw. sollten die Notfall-Shell nicht löschen (stattdessen nur Warnung anzeigen), es sei denn, der angegebene Fehler würde die Anmeldung der Konsole absolut unmöglich machen. Was ausgeführt werden kann, sollte ausgeführt werden.

Ich weiß, dass systemd automatisch * .mount-Dateien aus / etc / fstab generiert und ich könnte die Option nofail mit einem kleinen Timeout für x-systemd.device verwenden (oder die relevanten .mount-Dateien selbst definieren). Allerdings würde es mein Problem nicht lösen. Ich möchte das System widerstandsfähiger machen. Das "Patchen" von fstab jedes Mal ist nicht sehr praktisch und ich bin mir nicht sicher, wie viele andere mögliche "Probleme" existieren, die mein System nur deshalb nicht bootfähig machen würden Einige Entwickler hielten es irgendwo für wichtig genug.

In gewisser Weise möchte ich die Kontrolle über meinen Computer wiedererlangen und systemd nicht entscheiden lassen, welches Problem ernst genug ist, um den Startvorgang zu unterbrechen. Ist es möglich?


Was ist übrigens das eigentliche Problem? Mir sind zwei bekannt - ich kann mich nicht über ssh anmelden, und die Sulogin-Eingabeaufforderung ermöglicht nur Root- und nicht Sudo-Benutzern den Zugriff im Notfallmodus. decken diese die Schäden ab, die Sie erlitten haben?
Sourcejedi

Tatsächlich wäre das System viel zugänglicher, wenn diese beiden Dienste gestartet würden, ja. Optimalerweise sollte das System alles starten, was wie in den alten SysV-Zeiten gestartet werden kann (Fehlerprotokollierung statt schmerzhafter Tod durch Notfall-Shell), und die Shell nur im Falle eines schwerwiegenden Fehlers starten.
Goteguru

Antworten:


7

Es sind buchstäblich nur Mount-Fehler, das ist alles, was Sie ändern müssten.

Der Brief Ihrer Anfrage wäre also trivial zu beantworten. Erstellen Sie eine Drop-In-Datei:

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

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

Ich glaube, dies wird kein neues Problem hinzufügen, das über das hinausgeht, unter dem Linux Sysvinit bereits gelitten hat, als es dieses Szenario mit teilweisem Ausfall zugelassen hat.


Sie haben jedoch auch auf die Frage hingewiesen, wie lange systemd warten soll, bis die angegebenen Blockgeräte verfügbar sind. Ich sehe keine Möglichkeit, dies zu konfigurieren, ohne einen Ersatz für den gesamten fstab-Generator bereitzustellen. https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Wenn Sie hier eine große Menge weniger verbreiteten Codes ausgeben, ist es unwahrscheinlich, dass dies die Systemstabilität erhöht. Ich denke, die nächste Lösung wäre, den vorhandenen fstab-Generator zu patchen. Es ist nicht sehr komplex, ich vermute, Sie könnten damit durchkommen / mit bedeutenden Änderungen Schritt halten.

Wenn Ihre Distribution ein in sich geschlossenes mountallSysvinit-Skript hätte, könnten Sie versuchen, dies einzubinden. Aber das wird den Startvorgang erheblich verändern - es ist eigentlich eher eine Abzweigung. Ich würde diesen Ansatz nicht empfehlen.


/unix//a/393711/29483

Wenn Sie die Gerätedateien durchsuchen, gibt es nur sehr wenige Möglichkeiten, auf die der Boot zurückgreifen kann emergency.target. Dies ist normalerweise der .mountFall, wenn eine Einheit für ein lokales Dateisystem ausfällt und local-fs.target ausfällt. Oder wenn Ihr initramfs das Root-Dateisystem nicht bereitstellen kann, wenn Ihr initramfs systemd verwendet.

local-fs.targethat OnFailure=emergency.target. Und es schlägt fehl, weil Einheiten für lokale Dateisysteme automatisch zur Liste Erforderlich von local-fs.target hinzugefügt werden (sofern dies nicht der Fall ist DefaultDependencies=no).

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

2
Ich nehme an, ich sollte [Unit]\nOnFailure= in meine nofail.conf setzen. Es scheint möglich zu sein, die Wartezeit in /etc/systemd/system.conf zu konfigurieren (über die generische Option DefaultTimeoutStartSec). Meine Systeme sind normalerweise schnell genug, die 90er scheinen sowieso ein Overkill zu sein. Diese Lösung scheint vielversprechend zu sein.
Goteguru

In meinem Fall setze ich OnFailure=in /lib/systemd/system/local-fs.targetstatt /etc/systemd(Ubuntu 16.04 auf AWS)
ThiagoAlves

@ThiagoAlves sollten Sie das nicht tun, es wird bei System-Upgrades überschrieben. Folgen Sie den Anweisungen in der Antwort oder bitten Sie um Klarstellung :-).
Sourcejedi

@sourcejedi Ich habe die Antwort versucht, aber es hat bei mir nicht funktioniert
ThiagoAlves

1
@ThiagoAlves Vielen Dank für Ihr Feedback. Ich habe die Antwort weniger zweideutig gemacht, damit wir klarer erkennen können, ob dies das Problem war oder nicht. Das heißt, ich frage mich, ob Sie sichergestellt haben, dass Sie [Unit]vorher aufgenommen haben OnFailure=.
Sourcejedi

0

Deaktivieren Sie die automatische Bereitstellung eines Dateisystems, das für den Startvorgang nicht unbedingt erforderlich ist, indem Sie noautodem /etc/fstabEintrag eine Bereitstellungsoption hinzufügen :

/dev/sdxy /u01 nfs defaults 0 0

zu:

/dev/sdyx /u01 nfs noauto 0 0

Mounten Sie das Dateisystem nach dem Start mithilfe einer Zeile in /etc/rc.local:

mount /u01

In diesem Beispiel wird NFS verwendet, es gilt jedoch auch für LUNs, die von einem Dateiserver importiert wurden.


1
Ja, ich kenne noauto, aber wenn ich die fstab jedes Mal ändern würde, wäre nofail eine viel bessere Wahl. Danke trotzdem.
Goteguru

0

Versuchen Sie das vielleicht?

systemctl mask emergency.service
systemctl mask emergency.target

4
Hast du das versucht? Was passiert, wenn systemd beim Booten auf einen Fehler stößt und das Notfallziel maskiert ist?
Stephen Kitt
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.