Dopo che è stato emesso un comando di spegnimento, 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 ???
Quindi cos'è esattamente "un lavoro fermo"?
Inoltre, perché a volte stima il tempo necessario, in modo abbastanza accurato, e altre volte può durare per sempre?
Risposta accettata:
systemd opera internamente in termini di una coda di "lavori". Ogni lavoro (semplificando un po') è un'azione da intraprendere:fermare, controllare, avviare o riavviare una particolare unità .
Quando (ad esempio) indichi a systemd di avviare un'unità di servizio , elabora un elenco di lavori di arresto e avvio per tutte le unità (unità di servizio, unità di montaggio, unità dispositivo e così via) necessarie per raggiungere tale obiettivo, in base ai requisiti e alle dipendenze delle unità, le ordina, in base alle relazioni di ordinamento delle unità , risolve e (se possibile) corregge eventuali contraddizioni personali e (se l'ultimo passaggio ha esito positivo) le mette in coda.
Quindi tenta di eseguire i "lavori" accodati.
È in esecuzione un processo di arresto per la sessione 1 dell'utente xy
L'unità nome visualizzato ecco la Session 1 of user xy . Questa sarà (dal nome visualizzato) una sessione unità, non un servizio unità. Questa è l'astrazione della sessione di accesso allo spazio utente gestita da logind di systemd programma e i suoi plugin PAM. È (in sostanza e in teoria) un raggruppamento di tutti i processi che quell'utente sta eseguendo come una "sessione di accesso" da qualche parte.
Il lavoro che è stato accodato è stop . E probabilmente ci vorrà molto tempo perché le persone di systemd hanno erroneamente confuso la sessione riaggancia con la sessione spegnimento . Rompono il primo per far funzionare il secondo e in risposta alcune persone alterano il sistema per rompere il secondo per far funzionare il primo. Le persone di sistema dovrebbero davvero riconoscere che sono due cose diverse.
Nella tua sessione di accesso, hai qualcosa che ignora SIGTERM o che impiega molto tempo per terminare una volta che ha visto SIGTERM . Ironia della sorte, il primo è il comportamento di vecchia data di alcuni gusci di controllo del lavoro. Il modo corretto per terminare i leader della sessione di accesso quando sono queste particolari shell di controllo del lavoro è dire loro che la sessione è stata riattaccata , dopodiché terminano tutti i loro job (un tipo diverso di job rispetto al job systemd interno) e poi si chiudono da soli.
In realtà, systemd sta aspettando il timeout di arresto dell'unità fino a quando non ricorre a SIGKILL . Questo timeout è configurabile per unità, ovviamente, e può essere impostato per non scadere mai. Ecco perché si possono potenzialmente vedere comportamenti diversi.
Ulteriori letture
- Lennart Poettering (2015). sistema. pagine di manuale di sistema. Freedesktop.org.
- Jonathan de Boyne Pollard (01-06-2016). systemd interrompe i processi in background dopo che l'utente si è disconnesso . 825394. Rilevatore di bug Debian.
- Lennart Poettering (2015). systemd.kill. pagine di manuale di sistema. Freedesktop.org.
- Lennart Poettering (2015). servizio.sistema. pagine di manuale di sistema. Freedesktop.org.
- Perché bash ignora SIGTERM?
- https://superuser.com/questions/1102242/