Se SUSE Linux Enterprise Server si blocca durante lo spegnimento tramite systemd, identifica l'unità con un processo di arresto in esecuzione o esamina i messaggi finali dell'avvio precedente, quindi correggi tale unità o una sua dipendenza. Un'unità è una risorsa gestita da systemd, come un servizio o un punto di montaggio; un processo di arresto è la richiesta di systemd di arrestarne una. Non ridurre il timeout globale né forzare lo spegnimento come prima soluzione, perché un servizio o un filesystem potrebbero essere ancora in fase di chiusura di file o scrittura di dati.
Questa procedura dettagliata si basa sulla documentazione di SLES 15 SP7 verificata nell'ottobre 2026. La politica di arresto esatta dipende dal fornitore del servizio e dello storage, pertanto si consiglia di fare riferimento alle loro linee guida per eventuali modifiche specifiche dell'unità.
Se la console mostra "È in corso un'operazione di arresto per..." con un conto alla rovescia, annota il servizio o il punto di montaggio specificato e se il timer cambia. Ciò significa che systemd è in attesa dell'operazione di arresto di tale unità, non necessariamente che il sistema operativo si sia bloccato; i database e lo storage remoto potrebbero aver bisogno di tempo per chiudersi correttamente.
Monitorare il sistema tramite console remota o seriale, oppure tramite un altro terminale disponibile. Evitare comandi di reset o di accensione/spegnimento mentre sono in corso operazioni di scrittura. Se il sistema smette di rispondere, annotare l'ultima riga visualizzata e continuare dopo il riavvio.
Se SSH o un secondo terminale funzionano ancora, chiedi a systemd quali processi sono in esecuzione o in attesa, quindi controlla l'unità indicata sullo schermo:
sudo systemctl list-jobs
sudo systemctl status SERVICE.service
Sostituire SERVICEcon il nome effettivo dell'unità. Un processo di arresto in esecuzione restringe la ricerca, ma non spiega perché il processo non è terminato. Leggere lo stato e i log prima di modificare la configurazione. Se systemd non risponde più, non annullare i processi alla cieca; esaminare il journal precedente dopo il ritorno dell'host.
Il journal è il registro indicizzato di systemd dei messaggi del kernel, dei servizi e del sistema. Dopo il successivo avvio riuscito, elenca gli avvii registrati e controlla la fine dell'avvio precedente:
sudo journalctl --list-boots
sudo journalctl -b -1 -e
-1offset seleziona l'avvio precedente e -esi sposta sulle sue voci più recenti.Cerca l'ultimo messaggio "Arresto in corso", un timeout, dei tentativi o un dispositivo o un punto di montaggio specificato. L'ultima riga è solo un indizio: l'ordine di arresto potrebbe lasciare un'altra unità in attesa. Confronta i timestamp con i messaggi vicini.
Quando la schermata o il registro indicano un servizio, interroga solo le voci di avvio precedenti di tale unità. Esamina anche la configurazione caricata:
sudo journalctl -b -1 -u SERVICE.service --no-pager
sudo systemctl cat SERVICE.service
Verificare la presenza di un file personalizzato ExecStop, di uno script che attende indefinitamente, di un processo figlio persistente o di un errore dell'applicazione nel suo hook di arresto. Per le unità di terze parti, confrontare il pacchetto e la configurazione con le linee guida supportate prima di apportare modifiche.
Se il journal specifica un mount, un dispositivo o un filesystem remoto, ispeziona la tabella dei mount e la voce corrispondente in /etc/fstab:
sudo findmnt --verify --verbose
Verifica se una dipendenza remota NFS, CIFS, iSCSI o di altro tipo è raggiungibile e prevista durante lo spegnimento. Rimuovi una voce di montaggio obsoleta solo dopo aver verificato che non venga utilizzata. Non smontare forzatamente un filesystem attivo basandoti solo su un riavvio lento.
Per un servizio che non si arresta, correggere prima lo script di arresto, la configurazione dell'applicazione o il problema del pacchetto. Un drop-in per unità sudo systemctl edit SERVICE.serviceviene memorizzato in /etc/systemd/system/senza modificare il file del fornitore. Documentare SUSE TimeoutSecper l'avvio o l'arresto del servizio; utilizzare un valore approvato dal fornitore per questo carico di lavoro.
Dopo una modifica documentata, ricarica le definizioni delle unità di systemd con sudo systemctl daemon-reloade ispeziona il risultato con sudo systemctl cat SERVICE.service. Un timeout più lungo può consentire il completamento di uno spegnimento legittimo, ma può anche prolungare un riavvio non riuscito. Un timeout più breve può terminare un servizio prima che svuoti lo stato. Non modificare le impostazioni predefinite globali per nascondere il difetto di una singola unità.
SLES memorizza i dati del journal in /run/log/journal/una directory predefinita, che viene svuotata al riavvio. Se journalctl -b -1non sono presenti voci di avvio precedenti, abilitare la memorizzazione persistente del journal per future diagnosi:
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix=/var/log/journal
sudo journalctl --flush
I log persistenti utilizzano lo spazio sotto /var; SUSE fa notare che il journal può utilizzare fino al 10% di tale filesystem per impostazione predefinita. Verificare lo spazio libero e la conservazione, soprattutto su /varvolumi di piccole dimensioni.
Una volta risolta la causa sospetta, pianifica un riavvio controllato con accesso alla console. Dopo il riavvio del sistema, esamina i messaggi finali dell'avvio precedente e verifica lo stato attuale del servizio:
sudo journalctl -b -1 -e
sudo systemctl status SERVICE.service
Il problema si risolve quando il server si arresta senza attendere la stessa unità, si avvia normalmente e il servizio o il mount funzionano. Se i log terminano bruscamente o mostrano errori del kernel, del controller o dell'hardware, conservateli e indagate con SUSE o il fornitore dell'hardware invece di modificare i timeout.
Per i dettagli sui comandi, consultare la guida di systemd per SLES 15 SP7 e la guida di SUSE sui journal persistenti e sui filtri di journalctl . Questi passaggi identificano i potenziali blocchi; il servizio, il filesystem o la soluzione hardware corretta dipendono dall'unità indicata nei log della macchina.
Utilizza i processi systemd e il registro di avvio precedente per individuare un servizio, un punto di montaggio o una dipendenza di archiviazione che rallenta il sistema, quindi correggi il problema senza mascherarne la causa.
Utilizza firewall-cmd per ispezionare la zona attiva, consentire HTTP in modo sicuro, preservare l'accesso SSH e verificare che la regola sopravviva a un riavvio su SLES 15.
Individuare la causa di un errore PAM, ovvero il servizio, i criteri dell'account o il provider di identità, quindi ripristinare la corretta configurazione SLES preservando una sessione amministrativa funzionante.
Esegui il backup simultaneo dei file di Nextcloud e di MariaDB, pianifica snapshot crittografati di Restic tramite cron e verifica il ripristino senza mettere a rischio il server di produzione.
Configura HAProxy HTTPS, l'inoltro delle intestazioni, i timeout WebSocket e i controlli di integrità per ONLYOFFICE Docs, quindi verifica le modifiche e i salvataggi.
Installa i font personalizzati in ONLYOFFICE Document Server, confronta i mount Docker persistenti con le copie dirette, ricostruisci l'elenco dei font e verifica il risultato.
Diagnosticare i kill di MySQL OOM su Debian 12, verificare i limiti di memoria del VPS, configurare lo swap e ottimizzare la memoria e la concorrenza del database, senza promettere una soluzione universale.
Esporta una singola casella di posta Zimbra Community Edition, convalida il relativo backup TGZ e ripristina gli elementi mancanti senza sovrascrivere la posta esistente.
Consenti solo agli account approvati di avviare stanze Jitsi Meet utilizzando l'autenticazione tramite Keycloak e token, mantenendo al contempo la possibilità per gli ospiti di partecipare quando necessario.
Configura un server VPN WireGuard su Debian 12 per un client remoto. Configura le chiavi, l'inoltro IPv4, il NAT con nftables, l'accesso tramite firewall e i controlli di connessione.
