Che cosa è esattamente "un arresto", come in "Un arresto è in esecuzione ..."?

Dopo aver emesso un comando di arresto, a volte si riceve un messaggio di stato come questo:

A stop job is running for Session 1 of user xy

e poi il sistema si blocca per un po ', o per sempre a seconda di ???

Cos'è esattamente "un lavoro stop"?

Inoltre, perché a volte stima il tempo necessario, in modo abbastanza accurato, e altre volte può durare per sempre?

systemd opera internamente in termini di una coda di "lavori". Ogni lavoro (semplificando un po ') è un'azione da eseguire: arrestare, controllare, avviare o riavviare una determinata unità .

Quando (ad esempio) si ordina a systemd di avviare a un'unità di servizio , viene elaborato un elenco di lavori di arresto e avvio per qualsiasi unità (unità di servizio, unità di montaggio, unità del dispositivo e così via) necessaria per raggiungere tale obiettivo, in base a requisiti e dipendenze delle unità, le ordina, in base alle relazioni di ordinazione delle unità, risolve e (se possibile) corregge eventuali contraddizioni e (se quel passaggio finale ha esito positivo) le inserisce nella coda.

Quindi tenta di eseguire i "lavori" accodati.

È in esecuzione un processo di arresto per la sessione 1 dell'utente xy

Il nome visualizzato dell'unità qui è Session 1 of user xy. Questa sarà (dal nome visualizzato) un'unità di sessione , non un servizio un'unità di . Questa è l'astrazione della sessione di accesso dello spazio utente gestita dal logindprogramma di systemd e dai suoi plugin PAM. È (in sostanza e in teoria) un raggruppamento di tutti i processi che l'utente sta eseguendo come "sessione di accesso" da qualche parte.

Il lavoro che è stato accodato contro di esso è stop. E probabilmente ci vorrà molto tempo perché la gente del sistema ha erroneamente confuso il blocco della sessione con l' arresto della sessione . Rompono il primo per far funzionare il secondo, e in risposta alcune persone modificano il sistema per rompere il secondo per far funzionare il primo. Le persone sistemiche dovrebbero davvero riconoscere che sono due cose diverse.

Nella tua sessione di accesso, hai qualcosa che ignora SIGTERMo che richiede molto tempo per terminare una volta che ha visto SIGTERM. Ironia della sorte, il primo è il comportamento di vecchia data di alcune shell di controllo del lavoro. Il modo corretto di terminare i leader della sessione di accesso quando si tratta di queste particolari shell di controllo del lavoro è di dire loro che la sessione è stata bloccata , quindi terminano tutte le loro lavori (un diverso tipo di lavoro al lavoro interno del sistema) e quindi terminare se stessi.

Quello che sta realmente accadendo è che systemd sta aspettando il timeout di arresto dell'unità fino a quando non ricorre SIGKILL. Questo timeout è configurabile per unità, ovviamente, e può essere impostato su mai timeout. Ecco perché si possono potenzialmente vedere comportamenti diversi.

Ulteriori letture

• Lennart Poettering (2015). systemd . pagine di manuale di systemd. Freedesktop.org.
• Jonathan de Boyne Pollard (01/06/2016). systemd termina i processi in background dopo che l'utente si è disconnesso . 825394. Bug tracker Debian.
• Lennart Poettering (2015). systemd.kill . pagine di manuale di systemd. Freedesktop.org.
• Lennart Poettering (2015). systemd.service . pagine di manuale di systemd. Freedesktop.org.
• Perché bash ignora SIGTERM?
• /superuser/1102242/

Questi messaggi provengono da systemd, che è un sistema init che avvia e arresta i lavori. I lavori possono essere demoni, ma possono anche svolgere piccole attività come montare e smontare i dischi, eliminare / tmp o salvare e ripristinare la luminosità dello schermo durante l'avvio. systemctl list-unitsti dà l'idea. Systemd usa "unità" e "lavoro" per significare più o meno la stessa cosa.

Quando un lavoro viene interrotto, come nel caso systemctl stop ..., allora una domanda è quanto tempo deve attendere il completamento del lavoro prima di dichiarare l'errore e uccidere i processi del lavoro con il SIGKILLsegnale. Non vogliamo davvero usarlo a SIGKILLmeno che non sia necessario, in quanto non offre l'opportunità al processo di uscire in modo pulito. Per alcuni processi potrebbero essere necessari alcuni secondi per dichiarare l'errore, mentre per altri processi come un database potrebbero esserci sostanziali I / O di rete e del disco affinché il processo si arresti in modo pulito, e quindi potremmo concedere a tali unità alcuni minuti per spegnerlo in modo pulito .

Quello che vedi al momento dell'arresto è l'equivalente systemctl stop $UNIT_NAMEche sta impiegando del tempo per funzionare. C'è un contatore che mostra i secondi trascorsi e il tempo di attesa massimo prima che venga emesso SIGKILL e lo spegnimento procede indipendentemente.

A meno che non ci siano buone ragioni per aspettarsi un lungo ritardo, questo di solito indica una sorta di malfunzionamento. Ciò potrebbe variare da un server DHCP che non risponde a una versione e quindi l'azione di rilascio che deve scadere o da un errore che impedisce a un demone di non uscire mai.

Alcuni servizi sono bloccati e systemd è in attesa dell'uscita. Probabilmente Systemd non sta valutando con precisione il tempo necessario, il tempo (in genere 90 secondi) è il tempo che il sistema attende prima che finisca la pazienza. Vedi questo post:

È in esecuzione un processo di arresto per la sessione c2 dell'utente

"Interrompi lavori" è quando systemdè in attesa di un "lavoro" specifico, ad esempio un processo che è in attesa di essere completato prima di continuare. Se viene visualizzato un messaggio di avviso che "un processo di arresto è in esecuzione ..." (ecc.) Significa tecnicamente che è in sospeso qualcosa nella coda dei lavori.

Tuttavia, prima di scavare attraverso l'intera coda dei lavori di sistema, tenere presente che a volte questi messaggi di avviso sono un risultato indiretto da fattori ambientali (in effetti, il messaggio viene persino fatto riferimento al loro repository GitHub come possibile bug).

Ad esempio: stavamo ricevendo messaggi relativi a "stop job" e non riuscivamo a capire perché .... risultasse che il disco era quasi esaurito e ha iniziato a comportarsi in modo strano nel sistema operativo.

L'aggiornamento del server a un disco più grande e il riavvio lo hanno risolto;)