Comment désactiver le comportement shell agressif d'urgence de systemd?


10

Par défaut, systemd passe à un shell d'urgence à la moindre erreur. Par exemple, si l'un des montages de fstab échoue pour une raison quelconque, le système devient immédiatement impossible à démarrer. Je gère des dizaines de systèmes de production divers et j'ai trouvé ce comportement très dommageable. (En fait, je pense que c'est un échec de conception majeur, mais c'est une opinion personnelle).

Je voudrais augmenter la résilience de démarrage du système. De manière optimale, le système devrait toujours démarrer, les pilotes, les supports manquants, etc. ne devraient pas abandonner le shell d'urgence (il suffit de montrer un avertissement à la place), sauf si l'erreur donnée rendrait la connexion à la console absolument impossible. Ce qui peut être exécuté, cela devrait l'être.

Je sais que systemd génère automatiquement des fichiers * .mount à partir de / etc / fstab et je pourrais utiliser l'option nofail avec un petit délai d'expiration x-systemd.device (ou définir moi-même les fichiers .mount pertinents). Cependant, cela ne résoudrait pas mon problème, je veux rendre le système plus résistant, "patcher" fstab à chaque fois n'est pas très pratique et je ne suis pas sûr du nombre d'autres "problèmes" possibles qui rendraient mon système impossible à démarrer simplement parce que un développeur quelque part pensait que c'était assez important.

En quelque sorte, j'aimerais reprendre le contrôle de ma machine et ne pas laisser systemd décider quel problème est suffisamment grave pour écraser le processus de démarrage. C'est possible?


quel est le problème réel btw? j'en connais deux - ne pas pouvoir se connecter via ssh, et l'invite sulogin ne permet aux utilisateurs root, pas sudo, d'accéder en mode d'urgence. ces dommages couvrent-ils les dommages que vous avez subis?
sourcejedi

En fait, le système serait beaucoup plus accessible si ces deux services étaient lancés, oui. Idéalement, le système doit démarrer tout ce qui peut être démarré comme dans les anciens temps SysV (erreur de connexion au lieu d'une mort douloureuse par shell d'urgence), et démarrer le shell uniquement en cas d'erreur fatale.
goteguru

Réponses:


7

Ce ne sont que des échecs de montage, c'est tout ce que vous devez changer.

La lettre de votre demande serait donc banale pour y répondre. Créez un fichier de dépôt:

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

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

Je crois que cela n'ajoutera aucun nouveau problème, au-delà de ceux que Linux Sysvinit a déjà subis en autorisant ce scénario d'échec partiel.


Cependant, vous avez également souligné la question de la durée pendant laquelle systemd devrait attendre que les périphériques de bloc spécifiés soient disponibles. Je ne vois aucun moyen de configurer cela, sans fournir un remplacement pour le générateur fstab dans son ensemble. https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Si vous videz une grande quantité de code moins largement utilisé ici, il semble peu probable d'augmenter la résilience du système. Je pense que la solution la plus proche serait de patcher le générateur fstab existant. Ce n'est pas extrêmement complexe, je pense que vous pourriez vous en tirer / suivre les changements importants.

Techniquement, si votre distribution avait un mountallscript sysvinit autonome , vous pouvez essayer de le brancher. Mais cela changera considérablement le processus de démarrage - il s'agit en fait plus d'une fourchette. Je ne recommanderais pas cette approche.


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

Si vous recherchez dans les fichiers d'unité, il n'y a que très peu de façons pour que le démarrage revienne emergency.target. C'est généralement quand une .mountunité pour un système de fichiers local tombe en panne, provoquant l' local-fs.target échec. Ou lorsque vos initramfs ne parviennent pas à monter le système de fichiers racine, si vos initramfs utilisent systemd.

local-fs.targeta OnFailure=emergency.target. Et il échoue car les unités des systèmes de fichiers locaux sont automatiquement ajoutées à la liste Requiert de local-fs.target (sauf si elles l'ont DefaultDependencies=no).

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

2
Je suppose que je devrais mettre [Unit]\nOnFailure= dans mon nofail.conf. Il semble possible de configurer le temps d'attente dans /etc/systemd/system.conf (via l'option générique DefaultTimeoutStartSec). Mes systèmes sont généralement assez rapides, les années 90 semblent de toute façon exagérées. Cette solution semble prometteuse.
goteguru

Dans mon cas, je me suis installé OnFailure=à la /lib/systemd/system/local-fs.targetplace de /etc/systemd(Ubuntu 16.04 sur AWS)
ThiagoAlves

@ThiagoAlves vous ne devriez pas faire cela, il sera écrasé lors des mises à niveau du système. Suivez les instructions de la réponse ou demandez des éclaircissements :-).
sourcejedi

@sourcejedi J'ai essayé la réponse mais cela n'a pas fonctionné pour moi
ThiagoAlves

1
@ThiagoAlves Merci pour vos commentaires. J'ai rendu la réponse moins ambiguë, afin que nous puissions être plus clairs quant à savoir si c'était le problème ou non. C'est à dire, je me demande si vous vous êtes assuré d'inclure [Unit]avant OnFailure=.
sourcejedi

0

Désactivez le montage automatique de tout système de fichiers non essentiel à l'opération de démarrage en ajoutant une noautooption de montage à son /etc/fstabentrée:

/dev/sdxy /u01 nfs defaults 0 0

à:

/dev/sdyx /u01 nfs noauto 0 0

puis montez le système de fichiers après le démarrage en utilisant une ligne dans /etc/rc.local:

mount /u01

Cet exemple utilise NFS mais il s'applique également aux LUN importés d'un serveur de fichiers.


1
Oui, je ne sais pas, mais si je changeais le fstab à chaque fois, nofail serait un bien meilleur choix. Merci quand même.
goteguru

0

Essayez cela peut-être?

systemctl mask emergency.service
systemctl mask emergency.target

4
Avez-vous essayé cela? Que se passe-t-il lorsque systemd rencontre une erreur lors du démarrage, avec la cible d'urgence masquée?
Stephen Kitt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.