Corso Linux / Servizi systemd, avvio automatico e log di boot

Su un sistema Linux che usa systemd, l’avvio passa normalmente da firmware e bootloader al kernel; systemd attiva poi servizi e altre unità. Per esaminare un servizio, controlla con systemctl sia lo stato corrente sia l’impostazione di avvio automatico e leggi con journalctl i messaggi dello stesso avvio. Essere attivo adesso ed essere abilitato all’avvio sono condizioni diverse.

Questa lezione introduce stato dei servizi, avvio e abilitazione. Il corso sulla diagnostica dei guasti tramite i log (in inglese) mostra come combinare più indizi per circoscrivere la causa.

Gli ambienti di riferimento sono macchine virtuali con installazioni ordinarie di Ubuntu 26.04 LTS o Rocky Linux 9. Container, Windows Subsystem for Linux (WSL) e altri rilasci possono differire per servizi e pacchetti. Prepara una console per il recupero e annota le versioni seguendo il corso sull’ambiente di prova in macchina virtuale (in inglese). I comandi di consultazione non richiedono di riavviare o fermare servizi; eventuali modifiche richiedono le autorizzazioni amministrative previste dal sistema.

Le fasi principali dell’avvio

Un normale PC o server inizia con il firmware, che inizializza l’hardware e individua il bootloader. Quest’ultimo carica il kernel e l’ambiente iniziale necessario. Il kernel prepara dispositivi, memoria ed esecuzione dei processi; il sistema di inizializzazione gestisce poi i servizi nello spazio utente. Alcuni firmware possono caricare direttamente il kernel, e l’ambiente iniziale può già usare systemd. Questa lezione si applica a sistemi in cui systemd è il processo con PID 1, cioè l’identificatore 1 del processo di inizializzazione. Altri sistemi di init e ambienti speciali possono richiedere comandi diversi.

ps -p 1 -o pid,comm,args
systemctl get-default

Controlla il nome e gli argomenti del processo nel primo risultato per capire se PID 1 è systemd. In un container potrebbe essere un altro programma. L’esempio di ps presuppone gli strumenti Linux procps-ng; Git Bash su Windows non offre la stessa interfaccia. Il secondo comando mostra il target predefinito, non un elenco dei servizi attualmente attivi. multi-user.target rappresenta comunemente un obiettivo multiutente senza interfaccia grafica; graphical.target include l’ambiente grafico. Un target raggruppa unità: non implica che tutti i servizi partano uno dopo l’altro in un’unica sequenza.

Unità systemd e dipendenze

systemd rappresenta gli oggetti gestiti come unità. Un’unità .service gestisce un servizio; .target raggruppa unità verso un obiettivo; .socket permette l’attivazione tramite socket; .timer programma un’attivazione nel tempo. Il pacchetto e l’unità del servizio devono essere realmente installati. Non indovinare il nome di un’unità per avviarla o fermarla su un server in produzione.

L’ordine di avvio segue dipendenze e regole di ordinamento, non semplici numeri. Impostare l’avvio dopo un’altra unità non crea automaticamente una dipendenza che ne richieda l’attivazione. Per esempio, l’ordinamento After= è distinto dalle relazioni Wants= e Requires=. Alcune unità partono in parallelo: la posizione in un elenco non basta a spiegare un avvio lento.

systemctl list-units --type=service --state=running
systemctl --failed

Il primo comando elenca le unità di servizio caricate e attualmente nello stato di esecuzione selezionato; il secondo elenca le unità in stato di errore. Un elenco vuoto di unità fallite non garantisce che l’applicazione risponda correttamente. Potrebbero servire verifiche della porta, dell’endpoint di risposta o dei log dell’applicazione.

Stato corrente e abilitazione all’avvio

active riguarda l’attivazione attuale dell’unità; il significato preciso dipende dal tipo di unità. Per un servizio, uno stato come active (exited) non significa che un processo sia ancora in esecuzione. enabled indica normalmente collegamenti d’installazione che consentono l’attivazione tramite un target, spesso durante l’avvio. Non garantisce che l’unità venga avviata con successo. Un servizio può essere active ma disabled, oppure enabled ma attualmente fallito. Un’unità static può non avere regole per l’abilitazione diretta e funzionare comunque come dipendenza o tramite un altro meccanismo di attivazione.

NAME.service è un segnaposto da sostituire con un’unità installata. La barra / nella tabella separa operazioni alternative: scegli un solo verbo, senza copiarla nel comando. Fermare un’unità essenziale, come il servizio SSH usato per l’accesso remoto, può disconnetterti. Verifica gli effetti e un percorso di recupero prima di modificare servizi in produzione.

Consultare un servizio senza modificarlo

systemd-journald.service è comune sui sistemi systemd, ma immagini minime o speciali possono comportarsi diversamente. I comandi seguenti interrogano soltanto lo stato:

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status può mostrare caricamento, stato attuale, processi e alcune voci recenti del journal. Se apre un visualizzatore a pagine, premi q per tornare alla shell. is-active può mostrare active, inactive o failed e restituire uno stato d’uscita diverso da zero se l’unità non è attiva. Anche status può terminare con uno stato non nullo per un’unità inattiva. is-enabled può stampare enabled, disabled, static o altre condizioni. Non interpretare static come un errore, né uno stato d’uscita zero come prova che il servizio sia in esecuzione.

Cosa sapere prima di modificare un servizio

Quando una modifica è necessaria, start e stop intervengono sullo stato attuale, mentre enable e disable riguardano l’attivazione automatica. restart ferma e riavvia un servizio, interrompendo potenzialmente connessioni o attività; se il servizio era inattivo, può avviarlo. reload chiede al servizio di rileggere la configurazione soltanto se supporta questa operazione, con effetti specifici del programma. enable --now richiede sia l’abilitazione sia l’avvio immediato. Un servizio disabilitato può ancora essere avviato manualmente o tramite dipendenze.

Dopo aver creato o modificato un file di unità può servire daemon-reload, affinché il gestore systemd rilegga le definizioni e ricostruisca le dipendenze. È diverso da restart, che riavvia il servizio, e dal suo reload, che riguarda la configurazione applicativa. Prepara backup e una finestra di manutenzione prima di modificare unità o configurazioni in produzione.

Leggere i log dell’avvio corrente con journalctl

Il journal di systemd può raccogliere messaggi di servizi, kernel e altre fonti. -b senza ulteriori argomenti seleziona l’avvio corrente; -u seleziona un’unità; -n 30 richiede le 30 voci più recenti che rispettano i filtri. Senza permessi adeguati potresti vedere soltanto una parte dei messaggi: un amministratore autorizzato può consultare gli altri. L’assenza di risultati non dimostra da sola che non ci siano stati errori.

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

Il primo comando mostra le ultime voci relative a quell’unità nell’avvio corrente. Il secondo mostra gli ultimi messaggi con priorità warning o più grave. Un avviso non è necessariamente la causa del guasto: considera orario e contesto. --no-pager evita il visualizzatore a pagine. --list-boots elenca gli avvii per cui esistono messaggi accessibili, con identificatori e intervalli temporali. Se manca un avvio precedente, conservazione, spazio disponibile o permessi possono renderne indisponibili i log. Verifica che i dati esistano prima di tentare una diagnosi del passato.

Diagnostica di un servizio che non parte

1. Conferma il nome esatto dell’unità e l’installazione del pacchetto. Non intervenire per tentativi su un servizio con un nome simile.
2. Usa systemctl status per leggere stato di caricamento, stato corrente, riepilogo del fallimento e messaggi recenti.
3. Con journalctl -b -u leggi un contesto più ampio della stessa unità nello stesso avvio. Cerca indicazioni di errori di configurazione, permessi, conflitti di porta o dipendenze fallite.
4. Esamina configurazione, risorse e dipendenze; salva un backup prima di modificarle. Non allentare indiscriminatamente i permessi sulla base di una sola riga di log.
5. Dopo aver corretto la causa, esegui soltanto l’azione necessaria in un momento accettabile, poi verifica sia is-active sia la risposta reale dell’applicazione.

Per un avvio lento, systemd-analyze critical-chain mostra una catena di unità rilevante per i tempi di avvio. Una durata elevata in systemd-analyze blame non prova da sola che quell’unità abbia rallentato tutto il sistema: contano parallelismo e dipendenze. Anche critical-chain ha limiti, per esempio con attivazione tramite socket e unità che non attraversano uno stato activating; non sostituisce l’analisi dei log.

Documentazione di riferimento

Il manuale ufficiale systemctl descrive stati e operazioni sulle unità; quello di journalctl illustra i filtri per avvio, unità e priorità. systemd.unit approfondisce le dipendenze. Consulta anche bootup per le fasi di avvio e systemd-analyze per le misure e i loro limiti. Queste sono le pagine della versione più recente: per opzioni e dettagli disponibili nel tuo rilascio, confrontale con i manuali installati.