Gestire i servizi con systemd

Modulo 6: Servizi e log · Tempo di lettura: 10 minuti

Obiettivo della lezione: Dopo questa lezione Lei sarà in grado di avviare, fermare e ricaricare i servizi e di farli partire all'avvio, di leggere lo stato di un servizio e di modificare in sicurezza un'impostazione di un servizio con un drop-in.

Concetti chiave: systemd, unit, service, systemctl, start, stop, restart, reload, enable, disable, --now, active, inactive, failed, systemctl --failed, drop-in, systemctl edit, daemon-reload, Restart=

Chi tiene tutto in funzione?

Su un server girano decine di programmi che devono essere sempre presenti: il server SSH, il server web, un database, la sincronizzazione dell'ora. Questi programmi si chiamano servizi (services, o daemon). Qualcuno deve avviarli all'accensione, tenerli d'occhio e riavviarli se si bloccano. Su Debian, Ubuntu, AlmaLinux e Rocky Linux se ne occupa systemd. È il primo programma che il kernel avvia (processo 1) e poi avvia tutto il resto.

systemd lavora con le unit: descrizioni di qualcosa che deve gestire. I tipi più importanti:

Si comunica con systemd tramite il comando systemctl. L'estensione .service si può omettere: systemctl status nginx equivale a systemctl status nginx.service.

Leggere lo stato

Il comando che userà più spesso:

anna@web1:~$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-11-09 08:12:44 CET; 3h 2min ago
       Docs: man:nginx(8)
    Process: 902 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 905 (nginx)
      Tasks: 3 (limit: 2275)
     Memory: 4.1M (peak: 6.3M)
        CPU: 213ms
     CGroup: /system.slice/nginx.service
             ├─905 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             └─906 "nginx: worker process"

nov 09 08:12:44 web1 systemd[1]: Starting nginx.service - A high performance web server...
nov 09 08:12:44 web1 systemd[1]: Started nginx.service - A high performance web server...

Lo legga dall'alto verso il basso:

• Il pallino prima del nome è verde per un servizio in esecuzione, bianco per uno fermo e rosso per uno non riuscito.
• Loaded indica dove si trova il file della unit e se il servizio parte all'avvio (enabled) oppure no (disabled).
• Active indica se in questo momento è in esecuzione (active (running)), fermo (inactive (dead)) o non riuscito (failed), e da quando.
• Main PID e CGroup mostrano quali processi appartengono al servizio.
• In fondo compaiono le ultime righe del log del servizio. Spesso lì è già scritto perché qualcosa non funziona; per saperne di più usi journalctl (lezione 6.2).

Avviare, fermare, riavviare e ricaricare

anna@web1:~$ sudo systemctl start nginx      # avviare ora
anna@web1:~$ sudo systemctl stop nginx       # arrestare ora
anna@web1:~$ sudo systemctl restart nginx    # arrestare e riavviare
anna@web1:~$ sudo systemctl reload nginx     # rileggere la configurazione senza arrestare

La differenza tra restart e reload è importante nella pratica. Con un restart il servizio si ferma per un attimo: le connessioni in corso vengono interrotte e, se la nuova configurazione contiene un errore, il servizio non riparte più e il Suo sito web è fuori uso. Con un reload il servizio rilegge la propria configurazione continuando a funzionare; in caso di errore nella configurazione, nginx mantiene quella vecchia. Dopo una modifica alla configurazione di nginx, Caddy, SSH e fail2ban usi quindi reload e verifichi prima la configurazione (nginx -t, sshd -t, fail2ban-client -t). Non tutti i servizi supportano il reload; systemctl reload-or-restart sceglie da solo.

All'avvio: enable e disable

Avviare e "avviare all'accensione" sono due cose diverse:

anna@web1:~$ sudo systemctl enable nginx         # d'ora in poi si avvia all'avvio del sistema
anna@web1:~$ sudo systemctl disable nginx        # non più all'avvio del sistema
anna@web1:~$ sudo systemctl enable --now nginx   # entrambi: avviare ora e all'avvio del sistema
anna@web1:~$ systemctl is-enabled nginx
enabled

Un errore classico: si avvia un servizio con start, tutto funziona e al riavvio successivo (per esempio dopo un aggiornamento del kernel, lezione 4.2) il servizio non c'è più. Per un nuovo servizio usi quindi enable --now.

Se vuole essere certo che un servizio non parta mai, nemmeno quando un altro servizio lo richiede, esiste mask: sudo systemctl mask <dienst>. Per annullare: unmask.

Che cosa non va?

Un solo comando mostra tutte le unit non riuscite:

anna@web1:~$ systemctl --failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION
● php8.4-fpm.service  loaded failed failed The PHP 8.4 FastCGI Process Manager

1 loaded units listed.

Ne faccia un'abitudine, per esempio dopo ogni riavvio e ogni upgrade (lezione 4.3): l'elenco deve essere vuoto. Una volta risolto il problema, rimuova la segnalazione con sudo systemctl reset-failed.

Una panoramica di tutti i servizi in esecuzione:

anna@web1:~$ systemctl list-units --type=service --state=running

Se è in esecuzione qualcosa che non conosce o non usa, scopra di che cosa si tratta. Ogni servizio non necessario è superficie di attacco superflua (lezioni 5.1 e 10.1).

File delle unit e drop-in

Un file di unit è un file di testo. La versione del pacchetto si trova in /usr/lib/systemd/system/ (sui sistemi più vecchi in /lib/systemd/system/). Quel file non va mai modificato: un aggiornamento del pacchetto lo sovrascrive. Le Sue modifiche vanno in un drop-in: un piccolo file che contiene solo le righe che vuole cambiare. Il modo più semplice è:

anna@web1:~$ sudo systemctl edit nginx

Si apre un editor con uno spazio vuoto tra due righe di commento. Ciò che scrive lì finisce in /etc/systemd/system/nginx.service.d/override.conf. Per esempio: riavviare automaticamente nginx se si ferma in modo imprevisto.

[Service]
Restart=on-failure
RestartSec=5s

Dopo il salvataggio, systemctl edit ricarica automaticamente la configurazione di systemd. Se modifica un file di unit in altro modo, esegua Lei:

anna@web1:~$ sudo systemctl daemon-reload
anna@web1:~$ sudo systemctl restart nginx

daemon-reload fa rileggere a systemd i file delle unit; il servizio stesso deve poi essere riavviato per usare la modifica. Il risultato completo (originale più drop-in) si vede con systemctl cat nginx.

Restart=on-failure è una buona abitudine per i servizi importanti. Non lo usi però per nascondere un errore reale: un servizio che va in crash e si riavvia ogni cinque secondi va analizzato nel log. Dopo alcuni fallimenti rapidi consecutivi systemd smette di riavviarlo (il limite predefinito è cinque avvii in dieci secondi) e imposta il servizio su failed.

Su AlmaLinux e Rocky Linux

systemd e systemctl funzionano esattamente allo stesso modo. Cambiano a volte solo i nomi dei servizi: il servizio SSH si chiama sshd, il server web della distribuzione si chiama httpd (Apache) o nginx, e il firewall firewalld.

Nella pratica

Il pannello VPS del Suo fornitore (presso WebOké e altrove) può spegnere, riavviare o "spegnere forzatamente" l'intero server. Quest'ultima opzione equivale a staccare la spina: i servizi non hanno modo di fermarsi correttamente e un database può danneggiarsi. All'interno del server usi sudo systemctl reboot o sudo shutdown -h now, e nel pannello il normale pulsante per spegnere o riavviare.

Riepilogo

• systemd avvia e sorveglia tutti i servizi; lo si comanda con systemctl.
• systemctl status mostra se un servizio è in esecuzione, se parte all'avvio e le ultime righe di log.
• start/stop/restart valgono per il momento attuale, enable/disable per l'avvio; per un nuovo servizio usi enable --now.
• Dopo una modifica alla configurazione: prima verificare, poi reload; systemctl --failed deve essere vuoto.
• Non modifichi mai il file di unit di un pacchetto, ma usi un drop-in con systemctl edit.

Quiz

Esercizio

Esercizio O6.1: Mappare i Suoi servizi. Sul Suo server compili un elenco di tutti i servizi in esecuzione (systemctl list-units --type=service --state=running) e verifichi che systemctl --failed sia vuoto. Per ogni servizio indichi che cosa fa e se Le serve. Scelga un servizio che non conosceva e scopra di che cosa si tratta (systemctl status, man). Poi, per un servizio importante, imposti Restart=on-failure in un drop-in e controlli con systemctl cat che sia presente.

Per approfondire

• Manuale di systemctl(1): https://manpages.debian.org/trixie/systemd/systemctl.1.en.html
• Manuale di systemd.service(5) (Restart=): https://manpages.debian.org/trixie/systemd/systemd.service.5.en.html
• Manuale di systemd.unit(5) (drop-in): https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html