Systemd e Service Management — Avviare, Fermare, Abilitare Servizi e Usare Journalctl

Hai appena installato un'applicazione sul server e devi farla partire. Oppure un servizio non risponde più e non sai dove guardare i log. Se lavori con Linux prima o poi ti trovi davanti a systemd. Il demone che gestisce i servizi, i socket, i mount, i timer. E quando qualcosa non funziona, saper usare systemd e journalctl fa la differenza tra cinque minuti di debug e un'ora di bestemmie.

Noi, di Meteora Web, gestiamo server dall'inizio — dal 2017. Abbiamo visto servizi che non partivano per un typo nel file unit, log che si accumulavano senza rotazione, startup che rallentavano l'intero sistema. Ogni volta il problema si risolve con le stesse poche decine di comandi. Non serve essere sysadmin certificati. Basta conoscere il lessico di base di systemd e applicarlo con metodo.

Questa guida ti porta dritto al punto: iniziare, fermare, riavviare un servizio; abilitarlo all'avvio; controllarne lo stato; e – la parte più preziosa – leggere i log con journalctl. Niente teoria astratta: comandi che funzionano, esempi veri, errori tipici. E se vuoi un quadro più ampio su Linux per sviluppatori e sysadmin, parti dal nostro pillar dedicato.

Come si avvia e ferma un servizio con systemd?

Il cuore di systemd è il comando systemctl. Con lui controlli ogni servizio. Lo schema è sempre lo stesso: systemctl [azione] [nome-servizio]. Il nome del servizio è il nome del file unit (senza estensione .service).

Avviare un servizio subito

sudo systemctl start nginx

Questo avvia Nginx immediatamente, ma non lo abilita all'avvio del sistema. Se riavvii il server, il servizio non riparte. Molti si scordano questo dettaglio e poi si chiedono perché dopo un reboot il sito è giù.

Fermare un servizio

sudo systemctl stop nginx

Ferma il processo. Se hai servizi che dipendono da questo, verranno fermati a cascata (altra comodità di systemd).

Riavviare un servizio

sudo systemctl restart nginx

Equivalente a stop + start. Utile dopo modifiche alla configurazione. Se vuoi evitare il downtime (es. carico alto), usa reload quando il servizio lo supporta:

sudo systemctl reload nginx

Questo dice a Nginx di ricaricare la configurazione senza chiudere le connessioni attive.

Controllare lo stato

systemctl status nginx

Mostra se è attivo, il PID, quanto è in esecuzione, l'ultimo quarto di righe di log. È il primo comando che eseguiamo quando un cliente dice “il sito non si vede”.

Errore comune: vedere "active (exited)" per servizi come networking – è normale, non è un demone che resta in esecuzione.

Come abilitare un servizio all'avvio del sistema?

Un servizio avviato con start non sopravvive a un riavvio. Per renderlo persistente:

Enable e disable

sudo systemctl enable nginx

Crea i link simbolici nei target di avvio appropriati. Da quel momento, a ogni boot systemd avvierà Nginx. Per rimuovere il comportamento:

sudo systemctl disable nginx

Vedere lo stato di enable

systemctl is-enabled nginx

Ritorna enabled, disabled o static (per servizi che non possono essere abilitati singolarmente).

Un comando che unisce start + enable

sudo systemctl enable --now nginx

Abilita all'avvio e avvia subito il servizio. È il nostro comando preferito quando configuriamo un nuovo server per un cliente: una riga, zero dimenticanze.

Nota: alcuni servizi (es. quelli con Type=oneshot) non supportano enable nel senso classico. Controlla la documentazione del tuo servizio.

Come consultare i log con journalctl?

Prima di systemd i log erano sparsi in /var/log/syslog, /var/log/messages, /var/log/nginx/access.log ecc. systemd ha centralizzato tutto in journald. Il comando per leggerlo è journalctl.

Leggere i log del sistema intero

journalctl

Butta fuori tutto – millemila righe. Da solo non serve a molto. Bisogna filtrare.

Log di un singolo servizio

journalctl -u nginx

Mostra solo i log generati dal demone Nginx. È già più utile, ma se il servizio è in esecuzione da giorni potresti avere centinaia di righe.

Ultimi N log

journalctl -u nginx -n 50

Ultime 50 righe. Il nostro default quando qualcuno segnala un errore recente.

Log in tempo reale

journalctl -u nginx -f

Come tail -f ma sui log di systemd. Perfetto per monitorare mentre si riproduce un bug.

Filtrare per intervallo di tempo

journalctl -u nginx --since "2025-12-01 10:00:00" --until "2025-12-01 12:00:00"

Data e ora in formato YYYY-MM-DD HH:MM:SS. Puoi usare anche yesterday, today:

journalctl -u nginx --since yesterday

Vedere solo gli errori

journalctl -p err -u nginx

Il parametro -p (priority) filtra per livello: emerg, alert, crit, err, warning, notice, info, debug.

Errore comune: usare journalctl senza sudo e vedere solo i propri log utente. I log di sistema richiedono privilegi.

Come si crea e modifica un file unit di systemd?

Non sempre vuoi gestire solo servizi esistenti. A volte devi creare un tuo demone – per un'applicazione Node.js, uno script Python, un worker. I file unit si trovano in /etc/systemd/system/ (per quelli custom) o /lib/systemd/system/ (per quelli di sistema).

Struttura minima di un file unit

[Unit]
Description=My Custom Python Service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=always
User=myappuser

[Install]
WantedBy=multi-user.target

[Unit]: descrizione e dipendenze (After dice a systemd di avviarsi dopo che la rete è su).
[Service]: comando, utente con cui eseguirlo, politica di riavvio. Restart=always riavvia il servizio se crasha – fondamentale per un worker.
[Install]: serve per l'abilitazione all'avvio.

Attivare il nuovo servizio

sudo systemctl daemon-reload       # ricarica i file unit
sudo systemctl enable --now myapp  # abilita e avvia

Se modifichi il file unit dopo la prima attivazione, riesegui daemon-reload prima di un restart.

Quali comandi systemd per diagnosticare un servizio che non parte?

Quando un servizio rifiuta di avviarsi, la procedura è sempre la stessa:

1. Verifica lo stato: systemctl status nome-servizio – le ultime righe di log spesso contengono l'errore.
2. Leggi il journal: journalctl -xu nome-servizio – -x aggiunge spiegazioni leggibili, -u filtra per unità.
3. Controlla la sintassi del file unit: systemd-analyze verify /etc/systemd/system/nome-servizio.service – segnala errori di sintassi.
4. Controlla i permessi e i path: systemd di solito esegue i servizi come utente specificato. Se lo script lancia file in una directory senza permessi, fallisce.

Noi abbiamo visto un caso in cui il servizio non partiva perché il path di ExecStart conteneva uno spazio non escapato. Un typo da niente, ma senza journalctl avremmo perso un'ora.

Cosa fare adesso

Hai gli strumenti. Mettili in pratica subito:

1. Accedi a un server Linux (anche una VM locale) e avvia un servizio tipo Nginx o Apache con systemctl start.
2. Abilitalo all'avvio con systemctl enable --now.
3. Rompi qualcosa (intenzionalmente): cambia una configurazione, ferma il servizio, guarda il log con journalctl -u servizio -n 20.
4. Crea un file unit per uno script semplice (es. uno che scrive "Hello" ogni minuto con un timer) e testalo.
5. Leggi la documentazione ufficiale di systemd: systemctl man page — è il tuo miglior amico.

Systemd non è un mostro. È un kit di comandi preciso e potente. Quando un servizio non parte, non serve sapere tutto di Linux: basta avere una sequenza mentale chiara. E quella sequenza, adesso, ce l'hai.