Comment ignorer le délai d'expiration des années 90 dans systemd

Est-il possible de sauter interactivement le délai d'expiration des années 90 dans systemd? Par exemple, lorsqu'il attend qu'un disque soit disponible ou que l'utilisateur se déconnecte? Je sais que cela finira par échouer, alors puis-je le faire échouer maintenant? Je déteste juste regarder l'écran impuissant.

systemd systemd-boot

— user7610
source

Vous avez deux options:

Vous pouvez définir TimeoutStopSpec=sur une UNITÉ spécifique une valeur spécifique (en secondes *) pour attendre. Vous pouvez également le définir infinitydans quel cas SIGKILL ne sera jamais envoyé (non recommandé car vous pourriez vous retrouver avec des services incontrôlables difficiles à déboguer).
Définissez à l' DefaultTimeoutStopSec=intérieur /etc/systemd/system.conf(ou user.conf, ou dans l'un des *.drépertoires) une valeur par défaut que toutes les UNITÉS qui n'auront pas TimeoutStopSpec=spécifié utiliseront. Le sourd pour ce paramètre est les années 90 que vous voyez normalement.

Références de la page de manuel:

man systemd.service pour TimeoutStopSpec=
man systemd-system.conf pour DefaultTimeoutStopSec=

_{* systemd accepte également les spécifications de temps, par exemple "2min 3s". Cela est largement décrit dans l'homme.}

— grochmal
source

Ce n'est pas interactif. Lorsque le systemd est déjà en train de décompter les années 90, il est trop tard pour effectuer ces changements et je suis obligé de m'asseoir sans aide.

— user7610

@JiriDanek - c'est parce que systemd n'est pas interactif, il n'est pas censé l'être. Votre processus tty (dans lequel vous voyez les années 90) s'exécute comme un enfant d'init (sytemd), c'est-à-dire que le processus affichant (getty) les années 90 est un enfant du processus les comptant (systemd). De plus, systemd ignore la plupart des signaux. systemd n'est pas censé être contrôlé par un utilisateur aléatoire devant un tty (ce qui constituerait un énorme risque pour la sécurité).

— grochmal

Je suis principalement un utilisateur de bureau, j'ai donc tendance à voir les choses différemment. Vous vous souvenez de l'imprimante de la fille de Torvalds ? De nombreuses insuffisances de conception peuvent être justifiées par des problèmes de sécurité.

— user7610

@JiriDanek - systemd n'est pas un problème , ce serait un véritable vecteur d'attaque. Si vous pouviez viser un signal correct au bon moment, vous pourriez (en tant qu'utilisateur commun) désactiver un service système (par exemple SELinux). Allez simplement dans /etc/systemd/system.con et ajoutez DefaultTimeout = 3. Ou, mieux, corrigez le service qui échoue. Le fait que certains services échouent toujours n'est pas une mauvaise conception de systemd, c'est une mauvaise conception de la personne qui a écrit le fichier d'unité.

— grochmal

Dans mon cas particulier, l'auteur du fichier d'unité est innocent. Je viens de faire une faute de frappe lors du copier-coller d'un UUID de disque. J'ai simplement trouvé irritant de devoir attendre une minute et demie avant que systemd n'abandonne le montage et me permette d'entrer dans le système et de résoudre le problème. Le long délai d'attente est en fait logique ici. Sauf quand l'administrateur me le dit.

— user7610

Ce n'est pas possible. Systemd n'est pas interactif.

— user7610
source

Vous pouvez décommenter dans /etc/systemd/system.confles lignes:

DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=90s

Et changez la valeur en ce que vous jugez approprié.

— Msegade
source

Identique à l'autre réponse, ce n'est pas interactif. Lorsque le systemd compte déjà le compte à rebours des années 90, il est trop tard pour effectuer ces changements et je suis obligé de m'asseoir malgré lui sans aide.

— user7610