Come saltare il timeout degli anni '90 in systemd


15

È possibile saltare interattivamente il timeout degli anni '90 in systemd? Ad esempio, quando è in attesa che un disco diventi disponibile o che l'utente si disconnetta? So che alla fine fallirà, quindi posso farlo fallire ora? Odio solo fissare lo schermo impotente.

Risposte:


11

Hai due opzioni:

  1. È possibile impostare TimeoutStopSpec=un'unità specifica su un valore specifico (in secondi *) per attendere. Puoi anche impostarlo su infinitynel qual caso SIGKILL non verrà mai inviato (non raccomandato in quanto potresti finire con servizi in fuga che sono difficili da eseguire il debug).

  2. Impostare DefaultTimeoutStopSec=inside /etc/systemd/system.conf(o user.conf, o in una delle *.ddirectory) su un valore predefinito che TimeoutStopSpec=verranno utilizzate da tutte le UNIT che non sono state specificate. L'impostazione predefinita per questa impostazione sono gli anni '90 che normalmente vedi.

Riferimenti della pagina man:

  • man systemd.service per TimeoutStopSpec=
  • man systemd-system.conf per DefaultTimeoutStopSec=

* systemd accetta anche specifiche temporali, ad es. "2min 3s". Questo è ampiamente descritto nell'uomo.


10
Questo non è interattivo. Quando il systemd conta già il conto alla rovescia degli anni '90, è troppo tardi per apportare queste modifiche e sono costretto a sedermi impotente.
user7610

@JiriDanek - questo perché systemd non è interattivo, non è pensato per esserlo. Il tuo processo tty (in cui vedi gli anni '90) viene eseguito come figlio di init (sytemd), ovvero il processo che mostra (getty) gli anni '90 è un figlio del processo che li conta (systemd). Inoltre, systemd ignora la maggior parte dei segnali. systemd non è pensato per essere controllato da un utente casuale di fronte a un tty (sarebbe un enorme rischio per la sicurezza).
grochmal

4
Sono principalmente un utente desktop, quindi tendo a vedere le cose in modo diverso. Ricordi la stampante della figlia di Torvalds ? Molte inadeguatezze progettuali possono essere giustificate da problemi di sicurezza.
user7610

@JiriDanek - systemd non è un problema , sarebbe un vero vettore di attacco. Se potessi indirizzare un segnale corretto al momento giusto potresti (come utente comune) disabilitare un servizio di sistema (ad esempio SELinux). Basta andare in /etc/systemd/system.con e aggiungere DefaultTimeout = 3. O, meglio, correggere il servizio che non funziona. Il fatto che alcuni servizi falliscano sempre non è una cattiva progettazione di systemd, è una cattiva progettazione della persona che ha scritto il file di unità.
grochmal

Nel mio caso specifico, lo scrittore del file unit è innocente. Ho appena fatto un refuso quando copia-incolla un UUID del disco. Ho semplicemente trovato irritante dover aspettare un minuto e mezzo prima che systemd smettesse di montarlo e mi permettesse di entrare nel sistema e risolvere il problema. Il lungo timeout in realtà ha senso qui. Tranne quando l'amministratore lo sa che non lo è.
user7610


6

Puoi commentare /etc/systemd/system.confle righe:

DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=90s

E cambia il valore in quello che ritieni appropriato.


7
Come l'altra risposta, questo non è interattivo. Quando il systemd conta già il conto alla rovescia degli anni '90, è troppo tardi per apportare queste modifiche e sono costretto a sedermi impotente.
user7610
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.