Risoluzione dei problemi relativi all’errore “Un processo di arresto è in esecuzione” su Linux durante l’arresto

Ti è mai capitato di ricevere il messaggio “È in esecuzione un processo di arresto” durante l’arresto della tua distribuzione Linux? Non sei il solo. Questa notifica spesso sospende il processo di arresto del sistema fino a 90 secondi, lasciando molti utenti perplessi.

Comprensione della funzione di sicurezza

Innanzitutto, è fondamentale riconoscere che il messaggio “È in esecuzione un processo di arresto” è una funzione di sicurezza integrata e non un problema del sistema.

Distribuzioni Linux come Ubuntu, Fedora e Arch sfruttano systemd per gestire le sequenze di avvio e spegnimento. Quando si avvia uno spegnimento, systemd non interrompe bruscamente l’alimentazione; invia invece un segnale chiamato SIGTERM a tutti i servizi e le applicazioni attivi. Nello scenario ideale, ogni programma riceve questo segnale, consentendogli di salvare i propri dati e chiudere correttamente i file.

Tuttavia, alcuni servizi potrebbero richiedere più tempo per completare i loro processi e potrebbero non rispondere tempestivamente al segnale. Questo ritardo determina la visualizzazione del messaggio di avviso. Tra i motivi più comuni figurano:

gestori di rete
Servizi di container
Sessioni utente
Unità montate in rete

Molti utenti considerano il messaggio “A Stop Job is Running” come sintomo di un sistema difettoso, ma questo comportamento è stato intenzionalmente progettato dagli sviluppatori di systemd. In sostanza, l’attesa di 90 secondi consente ai servizi di completare le attività in sospeso. Se non vengono completate entro questo periodo, systemd le interromperà forzatamente tramite SIGKILL e procederà con l’arresto.

Questo arresto controllato garantisce che le applicazioni possano finalizzare le loro operazioni, dalla chiusura dei file al completamento delle transazioni del database, fino allo smontaggio pulito dei file system. Sebbene sia possibile ridurre questo periodo di attesa e accelerare gli arresti, ciò comporta il rischio di perdita o danneggiamento dei dati, che potrebbe compromettere la stabilità dei file system.

Regolazione del timeout predefinito

Il timeout standard di 90 secondi spesso funziona bene per gli utenti con hardware datato, poiché soddisfa le esigenze di pulizia della maggior parte dei servizi. Tuttavia, per chi utilizza sistemi più moderni, questa durata potrebbe sembrare eccessiva.

Fortunatamente, è possibile modificare la configurazione del sistema e ridurre la durata del timeout per accelerare il processo di arresto.È possibile specificare un limite di tempo preciso per i servizi in sospeso.

Per iniziare, apri il terminale e utilizza il tuo editor di testo preferito per modificare il file di configurazione del sistema:

sudo nano /etc/systemd/system.conf

Una volta aperto il file, cerca la variabile timeout. Troverai diverse impostazioni globali. Individua la riga che riporta #DefaultTimeoutStopSec=90s. La presenza di un simbolo cancelletto indica che è commentata, il che implica che il sistema sta utilizzando l’impostazione predefinita di 90 secondi.

Per modificare questa impostazione, rimuovere il simbolo cancelletto e modificare il valore impostando la durata desiderata.

Importante: impostare questo valore su 0 comporta un timeout indefinito, ovvero il sistema si bloccherà indefinitamente in attesa della terminazione dei processi. Un intervallo ragionevole compreso tra 20 e 30 secondi è in genere un compromesso accettabile.

Dopo aver completato le modifiche, salva e chiudi l’editor. Tieni presente che normalmente è necessario riavviare il computer per applicare queste modifiche. Potresti riscontrare nuovamente una lunga attesa, ma i successivi avvii rifletteranno la nuova impostazione di timeout.

Quando il timeout segnala un problema

In generale, il timeout di un processo di arresto è un comportamento previsto. Tuttavia, ritardi persistenti possono indicare problemi di fondo, soprattutto se lo stesso servizio prolunga costantemente l’arresto. Possibili spiegazioni includono mount di rete irraggiungibili, daemon configurati in modo errato o servizi che non rispondono ai segnali di arresto.

Se si osserva che i processi di spegnimento richiedono tempi insolitamente lunghi, che si estendono nell’ordine di minuti anziché secondi, potrebbe essere opportuno indagare sulle anomalie. Mentre i ritardi poco frequenti sono solitamente irrilevanti, quelli frequenti potrebbero richiedere la vostra attenzione.

Per identificare quale servizio sta causando il rallentamento, esaminare i registri dopo il riavvio dopo un arresto prolungato:

journalctl -b -1 -e

Questo comando recupera i log dell’avvio precedente e li porta alla fine.È possibile scorrere per trovare avvisi o messaggi di timeout relativi ai servizi che sono stati arrestati forzatamente.

Per restringere ulteriormente la ricerca, puoi filtrare i messaggi di livello di avviso utilizzando:

journalctl -b -1 -p warning

Inoltre, potresti voler utilizzare il seguente comando systemd:

systemd-analyze blame

Sebbene questo comando si concentri in genere sui tempi di avvio, i servizi lenti durante l’avvio spesso mostrano un comportamento simile durante l’arresto. I servizi tipici che possono attivare notifiche di “arresto processo” includono:

Servizi di rete
File system remoti come NFS o SMB
Server di database
Gestori di macchine virtuali e contenitori
Unità esterne e servizi di montaggio automatico

I servizi che si basano su mount basati sulla rete sono particolarmente vulnerabili ai ritardi quando la connettività è compromessa. Sebbene la riduzione del timeout di arresto possa accelerare gli arresti, non risolve i problemi di servizio che causano i ritardi. Affrontare le cause profonde offre una soluzione più sostenibile.

Conclusione

Linux offre agli utenti un controllo significativo sui propri sistemi, inclusa la possibilità di gestire i tempi di spegnimento per i servizi recalcitranti. Ottimizzando le applicazioni in background e disabilitando i servizi superflui, è possibile migliorare l’efficienza sia in fase di spegnimento che di avvio.

Fonte e immagini