Comando systemctl in Linux: stato, avvio e abilitazione dei servizi

systemctl consulta e gestisce le unità di systemd, tra cui i servizi: permette di avviarle, fermarle e configurarne l'attivazione. Per diagnosticare un servizio, inizia da status e distingui lo stato attuale dalle impostazioni di avvio.

Un'unità è un elemento gestito da systemd, per esempio un servizio .service, un socket o un timer. start avvia adesso, mentre enable configura i collegamenti di attivazione previsti dall'unità, spesso per l'avvio del sistema. I due comandi non si sostituiscono: active ed enabled descrivono aspetti diversi.

Sintassi di base

systemctl [opzioni] COMANDO [UNITÀ]

È uno schema: le parentesi indicano parti facoltative e non vanno digitate. Questa guida usa il gestore di sistema, normalmente systemd come PID 1; --user si rivolge invece al gestore del singolo utente e ha un ambito distinto. Un sistema con un altro sistema di init, o un container senza un gestore systemd raggiungibile, non offre automaticamente le stesse operazioni. Consulta man systemctl per la versione installata.

Esempi di consultazione

Leggere lo stato di un servizio

systemctl status sshd.service

Sostituisci sshd.service con il nome realmente installato: alcune distribuzioni usano ssh.service. Per cercarlo, consulta systemctl list-unit-files --type=service. Nel risultato di status, leggi Loaded per la definizione e l'abilitazione, Active per lo stato e il sottostato, poi i messaggi recenti del journal. Esci dall'eventuale pager con q.

Verificare se l'unità è attiva

systemctl is-active sshd.service

Il risultato sintetico può essere active, inactive, failed o un altro stato. Per una sola unità, il codice di uscita è zero se è attiva e diverso da zero altrimenti; controllalo subito con echo $?. Se passi più unità, un esito zero può significare che ne è attiva soltanto una: non equivale a verificarle tutte.

Controllare l'abilitazione

systemctl is-enabled sshd.service

Leggi il valore restituito separatamente dallo stato attuale. Oltre a enabled e disabled, puoi incontrare static, masked o stati validi soltanto fino al riavvio. static indica che mancano le normali istruzioni di abilitazione nella sezione [Install], ma l'unità può essere richiamata da dipendenze. Non interpretare il solo codice zero di is-enabled come prova che l'output sia esattamente enabled: anche alcuni altri stati, tra cui static, hanno esito zero.

Distinguere stato attivo e abilitazione

Ripetendo il controllo su un servizio presente nel sistema:

systemctl is-active sshd.service

Un possibile risultato, qui soltanto illustrativo, è:

active

active indica che systemd considera l'unità attiva. Per un demone può corrispondere a active (running), ma un servizio oneshot con RemainAfterExit=yes può essere active (exited) dopo la fine del processo. Lo stato non dimostra da solo che un sito risponda correttamente o che un'applicazione abbia completato ogni operazione: verifica anche il sottostato, i log e la funzione effettiva del servizio.

Un servizio attivo può essere disabilitato per l'avvio, mentre uno abilitato può essere fermo o fallito. Anche disabled non impedisce ogni avvio: una dipendenza o un'attivazione tramite socket può ancora richiamare l'unità. enable configura l'attivazione, senza garantirne il successo al prossimo avvio.

Dopo una modifica al file di unità, sudo systemctl daemon-reload fa rileggere a systemd le definizioni e le dipendenze. Non riavvia il servizio e non gli fa rileggere automaticamente la configurazione dell'applicazione. Per quella configurazione usa reload, se il servizio lo supporta, oppure pianifica un riavvio quando necessario. Per indagare, journalctl -u sshd.service mostra le voci accessibili del servizio nel journal; status ne presenta soltanto un riepilogo recente.

Comandi principali

Precauzioni prima delle modifiche

Le consultazioni sono diverse dai comandi che modificano il sistema. Per intervenire su unità di sistema servono le autorizzazioni previste dalla macchina, normalmente tramite sudo o una politica di autorizzazione. Prima di stop o restart, verifica nome, dipendenze, finestra di intervento e procedura di ripristino, soprattutto per accesso remoto e servizi web. Le consultazioni degli esempi non richiedono di riavviare SSH.

Conserva la configurazione precedente e applica solo la modifica necessaria. Dopo l'intervento ricontrolla stato, log e funzionamento reale. Non usare enable per correggere alla cieca un servizio fallito e non confondere daemon-reload con reload: agiscono su configurazioni diverse.

Domande frequenti

systemctl enable avvia immediatamente il servizio?

Senza altre opzioni, no. Per un'unità che supporta l'abilitazione, sudo systemctl enable --now NOME.service combina abilitazione e avvio; sostituisci il nome e verifica entrambi gli esiti. Analogamente, disable senza --now non ferma un'unità già attiva. Un avvio riuscito non garantisce che l'applicazione risponda correttamente.

Confrontare gli stati con un'unità di laboratorio

Usa una VM dedicata al laboratorio, con systemd come PID 1, una shell compatibile con sh, sudo, systemd-analyze e /usr/bin/true. Il blocco crea un nuovo servizio oneshot, cioè un'azione che termina anziché un processo permanente, senza fermare servizi SSH o web. Modifica temporaneamente l'abilitazione all'avvio: completa anche la pulizia descritta sotto.

Prima di eseguirlo, verifica che il nome lf-systemctl-lab.service non identifichi già un'unità, un alias o personalizzazioni della VM. Il blocco rifiuta nomi presenti nel catalogo e file o drop-in omonimi nella destinazione locale; non sostituisce il controllo di eventuali percorsi personalizzati o drop-in generali della macchina. Se trovi una collisione, interrompi e scegli un nome nuovo in tutti i riferimenti, compresa la pulizia.

(
set -eu
unit=lf-systemctl-lab.service
file=/etc/systemd/system/$unit
known=$(systemctl list-unit-files --no-legend "$unit")
if [ -n "$known" ]; then
    printf 'Nome di unita gia presente; interrompere il laboratorio.\n' >&2
    exit 1
fi
test -x /usr/bin/true
if sudo test -e "$file" || sudo test -L "$file" ||
   sudo test -e "$file.d" || sudo test -L "$file.d"; then
    printf 'Il nome del laboratorio esiste gia; interrompere e scegliere un altro nome.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Laboratorio Linux Factory sugli stati di systemctl
[Service]
Type=oneshot
ExecStart=/usr/bin/true
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
systemctl is-active "$unit"
sudo systemctl enable "$unit"
systemctl is-enabled "$unit"
sudo systemctl stop "$unit"
systemctl is-active "$unit" || true
systemctl is-enabled "$unit"
sudo systemctl disable "$unit"
systemctl is-enabled "$unit" || true
)

Gli esiti attesi sono: dopo start, active; dopo enable, enabled; dopo stop, inactive ma ancora enabled; dopo disable, disabled. RemainAfterExit=yes mantiene attivo lo stato del servizio dopo che /usr/bin/true è terminato. I due || true permettono al blocco di proseguire dopo i controlli attesi come negativi: leggi comunque output ed eventuali errori, perché non certificano il successo.

Per ripristinare la VM, verifica che /etc/systemd/system/lf-systemctl-lab.service sia ancora il file creato qui, senza modifiche altrui. Esegui sudo systemctl disable --now lf-systemctl-lab.service, rimuovi soltanto quel file con sudo rm -- /etc/systemd/system/lf-systemctl-lab.service e infine esegui sudo systemctl daemon-reload. Controlla che il file sia assente e che non restino collegamenti di abilitazione del laboratorio. Se il blocco si ferma per un errore, esamina e ripulisci soltanto lo stesso elemento; non cancellare directory o altre unità.

Documentazione di riferimento

Il manuale systemctl di systemd descrive comandi, stati e codici di uscita. Il manuale systemd.service spiega i servizi oneshot e RemainAfterExit.