systemctl: tutti i modi per elencare i servizi Linux

L'unico comando da conoscere: systemctl list-units --type=service

Su qualsiasi distribuzione che usa systemd — Ubuntu dalla 15.04, Debian dalla 8, RHEL e CentOS dalla 7, oltre a Fedora, Arch e openSUSE — ogni servizio è una unit di systemd, e systemctl è lo strumento che le elenca:

systemctl list-units --type=service

Per impostazione predefinita stampa ogni service unit che systemd ha attualmente in memoria: i servizi attivi, quelli con job in coda o quelli falliti. Non mostra i servizi installati ma mai avviati. Quando l'output è più lungo del terminale, systemctl lo invia a un pager (less) — premi q per uscire, oppure aggiungi --no-pager per stampare direttamente su stdout.

Ogni riga ha cinque colonne:

• UNIT — il nome della unit, per esempio ssh.service. È il nome esatto da passare a systemctl status, start e stop.
• LOAD — indica se il file della unit è stato interpretato correttamente: loaded, not-found, bad-setting, error o masked.
• ACTIVE — lo stato di alto livello: active, inactive, activating, deactivating o failed.
• SUB — lo stato di basso livello, specifico per il tipo di unit: un servizio può essere running, exited, dead e così via.
• DESCRIPTION — il testo leggibile descritto nel file della unit.

Leggi insieme la coppia ACTIVE/SUB: active (running) significa che un processo è attivo in questo momento, mentre active (exited) significa che un servizio oneshot è stato eseguito con successo e si è concluso — normale per i task di configurazione, non un problema da risolvere.

Filtrare: in esecuzione, falliti o tutto

L'opzione --state= filtra su qualsiasi valore di LOAD, ACTIVE o SUB e accetta elenchi separati da virgole:

# Only services with a live process
systemctl list-units --type=service --state=running

# Everything loaded, including stopped and dead services
systemctl list-units --type=service --all

# Only failures
systemctl list-units --type=service --state=failed

# Combine states
systemctl list-units --type=service --state=running,exited

systemctl --failed è una scorciatoia integrata per il filtro sui servizi falliti e vale la pena eseguirlo d'istinto su ogni macchina a cui accedi. Per un output leggibile dalle macchine, --no-legend rimuove l'intestazione e le righe di riepilogo mentre --plain rimuove i caratteri elenco, così le colonne restano stabili per awk o cut. Per cercare per nome, passa l'output a grep: systemctl list-units --type=service --all --no-pager | grep ssh.

Cosa parte all'avvio: systemctl list-unit-files

list-units risponde alla domanda "cosa è in esecuzione ora?". Per rispondere a "cosa partirà all'avvio?", elenca invece i file delle unit installati su disco:

systemctl list-unit-files --type=service
systemctl list-unit-files --type=service --state=enabled

Qui la colonna STATE descrive la configurazione di avvio, non lo stato di esecuzione:

• enabled — parte automaticamente all'avvio (o sul proprio trigger, per i servizi attivati da socket o timer).
• disabled — installato, ma nulla lo avvia automaticamente.
• static — non ha una sezione [Install]; viene eseguito solo come dipendenza di un'altra unit e non può essere abilitato direttamente.
• masked — collegato con symlink a /dev/null; systemd rifiuta di avviarlo del tutto.
• generated — creato a runtime da un generator, tipicamente a partire da uno script init legacy.

Le versioni recenti di systemd stampano anche una colonna preset (VENDOR PRESET o PRESET a seconda della versione) che indica quale sarebbe il valore predefinito della distribuzione. La trappola da evitare: abilitato non significa in esecuzione, e disabilitato non significa fermo. Un servizio può essere disabilitato ma in esecuzione perchè qualcuno lo ha avviato a mano, oppure abilitato ma morto perchè è andato in crash. Quando conta, verifica entrambi gli elenchi.

Un servizio alla volta: status, is-active, is-enabled

Quando un servizio attira la tua attenzione, entra nel dettaglio:

systemctl status nginx
systemctl is-active nginx    # prints: active | inactive | failed
systemctl is-enabled nginx   # prints: enabled | disabled | static | masked
systemctl is-failed nginx

status mostra il quadro completo: stato ACTIVE/SUB, PID principale, uptime, uso della memoria, l'albero dei processi cgroup e le ultime dieci righe del journal. Quando dieci righe non bastano, vai direttamente al journal con journalctl -xeu nginx (-u filtra per unit, -e salta alla fine, -x aggiunge testo esplicativo).

I comandi is-* sono pensati per gli script: stampano una sola parola e impostano il codice di uscita di conseguenza — is-active esce con 0 solo quando la unit è attiva, e is-enabled esce con un valore diverso da zero per le unit disabilitate o mascherate. Aggiungi --quiet per sopprimere l'output e conservare solo il codice di uscita.

Tutti i comandi di elenco visti sopra funzionano come utente senza privilegi. Gestire davvero i servizi — start, stop, enable, disable — richiede root, quindi conviene capire come funzionano sudo e il cambio utente su Ubuntu prima di andare oltre la semplice lettura dello stato. Nota inoltre che le unit a livello utente vivono in un manager separato: systemctl --user list-units --type=service elenca i servizi in esecuzione nella tua sessione, ed è il motivo per cui alcuni servizi sembrano "assenti" dall'elenco di sistema.

Riepilogo: gli elenchi che userai davvero

Flussi di lavoro reali

1. Trovare il servizio che continua a fallire

systemctl --failed
systemctl status myapp.service --no-pager -l
journalctl -xeu myapp.service
systemctl reset-failed myapp.service

Parti in modo ampio con --failed, poi leggi l'output di status per il codice di uscita e le ultime righe di log, quindi scava nel journal per la traccia completa. Una volta corretta la causa radice e riavviato il servizio, reset-failed cancella la voce di errore obsoleta così il prossimo controllo di salute parte pulito.

2. Verificare cosa partirà al prossimo avvio

systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'
systemd-analyze blame

Il primo comando ti dà un elenco pulito di tutto cio' che partirà automaticamente — utile prima di irrobustire un server o per rintracciare qualcosa che hai installato mesi fa e dimenticato. systemd-analyze blame mostra poi quanto tempo ha richiesto ogni unit durante l'ultimo avvio, ed è qui che i servizi lenti si notano subito.

3. Comandi rapidi per script e monitoraggio

systemctl is-active --quiet nginx && echo up || echo down
systemctl list-units --type=service --state=running --no-legend --plain | awk '{print $1}'
systemctl show -p ActiveState,SubState nginx
systemctl list-units --type=service -o json   # systemd 246 or newer

show -p stampa coppie Key=Value il cui formato non cambia mai tra le versioni, e l'output JSON si passa direttamente a jq. Se ti ritrovi a rieseguire gli stessi controlli a ogni accesso, racchiudili in un piccolo script — la nostra guida ai file .sh e allo scripting shell spiega come trasformare esattamente questo tipo di snippet in uno strumento riutilizzabile.

Niente systemd? service --status-all e OpenRC

Prima di dare per scontato che systemctl esista, verifica cosa gira davvero sulla macchina — controllare il sistema operativo e la versione dalla riga di comando richiede dieci secondi e ti dice se sei su una distribuzione con systemd. Se systemctl manca, sei su SysV init o su OpenRC:

service --status-all

Su Debian e Ubuntu questo comando percorre /etc/init.d e stampa [ + ] per i servizi in esecuzione, [ - ] per quelli fermi e [ ? ] per gli script senza comando status. Funziona ancora sulle distribuzioni con systemd tramite un livello di compatibilità, ma vede solo gli script init, quindi in quel caso preferisci systemctl. Su Alpine e Gentoo l'init system è OpenRC: rc-status elenca i servizi del runlevel corrente e rc-update show elenca cosa avvia ogni runlevel.

Tutto quanto sopra presuppone che tu abbia una macchina Linux su cui hai i permessi di root e puoi avviare, rompere e riparare i servizi liberamente. Se te ne serve una per esercitarti — o una macchina pulita per ospitare carichi di lavoro reali — un VPS Linux con accesso root completo di rdp.monster include CPU e RAM dedicate, banda illimitata (fair-use), nessun KYC, e viene consegnato circa 10 secondi dopo la conferma del pagamento, così puoi eseguire systemctl list-units sul tuo server entro un minuto.

Domande frequenti

Perchè un servizio mostra active (exited) invece di active (running)?

È un servizio oneshot eseguito con successo e concluso — non un errore.

I servizi con Type=oneshot (o RemainAfterExit=yes) eseguono un'attività una volta sola — montaggio, configurazione del firewall, pulizia — e terminano. systemd riporta allora active (exited): la unit è andata a buon fine ed è considerata "attiva", ma non resta alcun processo. Solo i demoni come nginx o sshd mostrano active (running). Se un servizio che ti aspetti sia un demone mostra exited, controlla il suo file di unit con systemctl cat name.service per vedere come è dichiarato.

Cosa significano i pallini colorati nell'output di systemctl?

Verde significa attivo, bianco inattivo e rosso fallito o in errore.

Il pallino prima del nome di una unit in systemctl status e systemctl list-units è un indicatore rapido di stato: verde per attivo, bianco per inattivo o in disattivazione e rosso per gli stati falliti o in errore. Anche le righe fallite sono evidenziate in rosso negli elenchi, il che rende systemctl --failed facile da leggere. Negli script o nei log dove i codici colore danno fastidio, aggiungi --plain o reindirizza l'output: le decorazioni scompaiono.

Esiste un equivalente systemctl di chkconfig --list?

Sì — systemctl list-unit-files --type=service sostituisce chkconfig --list.

Su RHEL e CentOS 7 o successivi, chkconfig --list è sostituito da systemctl list-unit-files --type=service, che mostra ogni servizio installato e se è enabled, disabled, static o masked. Per un singolo servizio, systemctl is-enabled name sostituisce chkconfig name e systemctl enable name sostituisce chkconfig name on. Il vecchio comando può esistere ancora come livello di compatibilità, ma copre solo gli script SysV legacy.

Come impedisco a un servizio di partire all'avvio?

Usa systemctl disable per toglierlo dall'avvio, o mask per bloccarlo del tutto.

Esegui sudo systemctl disable name per rimuovere il symlink di avvio; aggiungi --now per fermarlo anche subito. Un servizio disabilitato può comunque essere avviato manualmente o richiamato come dipendenza di un'altra unit. Se non vuoi che parta mai, usa sudo systemctl mask name, che collega la unit a /dev/null facendo fallire ogni tentativo di avvio. Puoi annullare l'operazione con systemctl unmask. Verifica il risultato con systemctl is-enabled name.