Creare Servizio systemd: Riavvio Automatico e Dipendenze

Creare un servizio systemd personalizzato è un’abilità fondamentale per ogni sysadmin che gestisce sistemi Linux in produzione. In un ambiente enterprise con centinaia di server e servizi custom, l’affidabilità e la gestione centralizzata diventano prioritarie. La configurazione di un unit file systemd non solo garantisce che un’applicazione o uno script vengano avviati correttamente all’avvio del sistema, ma permette anche di definire dipendenze, gestire riavvii automatici in caso di fallimento e isolare i processi per una maggiore sicurezza. Questo approccio riduce drasticamente i tempi di inattività e semplifica il troubleshooting, fornendo un controllo granulare sull’esecuzione dei processi critici. Leggi anche: 20 comandi Linux che ogni sysadmin dovrebbe conoscere a memoria

Testato su: Ubuntu 24.04 LTS · Debian 12 · CentOS Stream 9 · Settembre 2026

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di un sistema Linux con systemd (praticamente tutte le distribuzioni moderne lo usano). Assicurati di avere accesso come utente con privilegi sudo per creare e gestire i servizi. Non sono richiesti software specifici, se non un editor di testo come nano o vim.

Dove vanno gli unit file e quale scegliere

Gli unit file di systemd sono file di configurazione che descrivono come systemd deve gestire una risorsa (un servizio, un mount point, un socket, ecc.). La loro posizione è cruciale per il corretto funzionamento e per la manutenibilità del sistema.

Esistono diverse directory dove systemd cerca gli unit file, ordinate per priorità (l’ultima ha la precedenza):

/usr/lib/systemd/system/: Contiene gli unit file installati dai pacchetti del sistema operativo e dalle applicazioni. Questi file non dovrebbero essere modificati direttamente, poiché verrebbero sovrascritti dagli aggiornamenti del pacchetto.
/etc/systemd/system/: È la directory preferita per i servizi personalizzati e per le modifiche ai servizi esistenti. Qui puoi creare i tuoi unit file o sovrascrivere parti di unit file di sistema (utilizzando il meccanismo degli ‘override’ o ‘drop-in files’).
/run/systemd/system/: Utilizzata per unit file generati dinamicamente o temporanei. Non è una posizione per unit file manuali.

Per i nostri scopi, ovvero la creazione di un servizio personalizzato, la directory /etc/systemd/system/ è la scelta corretta. Creeremo un file app.service al suo interno.

Anatomia di un servizio: [Unit], [Service], [Install]

Un unit file di tipo service è tipicamente diviso in tre sezioni principali, ognuna con un ruolo specifico:

[Unit]: Questa sezione contiene metadati generici sull’unit, come una descrizione leggibile dall’utente (Description=) e le dipendenze da altre unit (After=, Requires=, Wants=). È qui che si definisce l’ordine di avvio e le relazioni con altri servizi.
[Service]: Questa è la sezione più importante per un servizio. Definisce il comando da eseguire (ExecStart=), l’utente sotto cui deve girare il servizio (User=), le direttive di riavvio (Restart=, RestartSec=) e altre opzioni di esecuzione.
[Install]: Questa sezione è utilizzata da systemctl enable per determinare come il servizio deve essere abilitato all’avvio. WantedBy= specifica sotto quale target il servizio deve essere abilitato (es. multi-user.target per un sistema multi-utente senza GUI).

Ecco un esempio di unit file di base per un’applicazione generica denominata app:

sudo nano /etc/systemd/system/app.service

Quindi incolla il seguente contenuto:

[Unit]
Description=App
After=network-online.target
Wants=network-online.target

[Service]
User=app
EnvironmentFile=/etc/app.env
ExecStart=/opt/app/bin/app
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Salva e chiudi il file. Questo file definisce un servizio semplice ma robusto. Leggi anche: HAProxy Linux: Guida Completa a Load Balancing e Alta Disponibilità (2026)

Avviare dopo la rete: After e Wants

Per molti servizi, specialmente quelli che comunicano su rete, è fondamentale che partano solo dopo che l’interfaccia di rete è completamente configurata e funzionante. Le direttive After= e Wants= nella sezione [Unit] gestiscono proprio questo.

After=network-online.target: Indica a systemd che questo servizio deve essere avviato dopo che network-online.target è stato raggiunto. network-online.target è un target speciale che di solito viene attivato solo quando le interfacce di rete sono attive e hanno un indirizzo IP.
Wants=network-online.target: Crea una dipendenza debole. Se network-online.target fallisce o non esiste, il nostro servizio cercherà comunque di avviarsi. Per una dipendenza più forte, useresti Requires=, che causerebbe il fallimento del nostro servizio se la dipendenza non fosse soddisfatta. Wants= è spesso sufficiente e più flessibile.

Queste direttive sono cruciali per evitare che i servizi tentino di connettersi a risorse di rete non ancora disponibili, prevenendo errori all’avvio.

Riavvio automatico con Restart e RestartSec

La resilienza è un aspetto chiave in produzione. systemd offre potenti meccanismi per garantire che i servizi critici rimangano attivi anche in caso di crash. Le direttive Restart= e RestartSec= nella sezione [Service] sono fondamentali per questo.

Restart=on-failure: Specifica quando il servizio deve essere riavviato automaticamente. Le opzioni comuni sono:
no: Non riavviare mai.
on-success: Riavvia solo se il processo termina con successo.
on-failure: Riavvia se il processo termina con un codice di errore, o se viene terminato da un segnale (ma non se è un riavvio pulito o un processo di spegnimento).
on-abnormal: Riavvia se il processo termina in modo anomalo (es. a causa di un segnale).
on-watchdog: Riavvia se il watchdog timer scade.
always: Riavvia sempre, indipendentemente dal codice di uscita.

on-failure è una scelta comune e robusta per la maggior parte delle applicazioni che non dovrebbero terminare inaspettatamente.

RestartSec=5: Definisce un ritardo in secondi prima che systemd tenti di riavviare il servizio. Questo è utile per evitare un ciclo di riavvio rapido che potrebbe sovraccaricare il sistema o nascondere un problema sottostante. Un valore di 5 secondi è un buon punto di partenza.

Con queste due direttive, systemd diventa un guardiano attivo del tuo servizio, intervenendo automaticamente in caso di problemi.

Eseguire come utente non privilegiato

Per ragioni di sicurezza, nessun servizio dovrebbe mai essere eseguito come utente root a meno che non sia strettamente necessario (e quasi mai lo è). La direttiva User= (e opzionalmente Group=) nella sezione [Service] consente di specificare l’utente e il gruppo sotto cui il servizio verrà eseguito.

Nell’esempio, User=app indica che il servizio verrà eseguito con l’utente app. Se questo utente non esiste, systemd fallirà l’avvio del servizio. È buona pratica creare un utente di sistema dedicato per ogni servizio, con privilegi minimi e una shell non interattiva (es. /sbin/nologin).

sudo useradd -r -s /sbin/nologin app

Questo isola il processo e limita i danni potenziali in caso di compromissione del servizio.

Variabili d’ambiente e EnvironmentFile

Spesso i servizi richiedono variabili d’ambiente per la loro configurazione (es. stringhe di connessione a database, chiavi API). Invece di hardcodarle nell’unit file, è preferibile caricarle da un file esterno utilizzando EnvironmentFile= nella sezione [Service].

EnvironmentFile=/etc/app.env

Il file /etc/app.env dovrebbe contenere le variabili nel formato KEY=VALUE, una per riga:

sudo nano /etc/app.env

DATABASE_URL=jdbc:postgresql://localhost:5432/myapp
API_KEY=your_secret_key

Assicurati che i permessi di questo file siano restrittivi (es. chmod 600 /etc/app.env) per proteggere le informazioni sensibili. Questo approccio migliora la sicurezza e la flessibilità, consentendo di modificare la configurazione senza toccare l’unit file principale. Leggi anche: Ansible vs Script: Gestire 200 Server

Abilitare, avviare e verificare il servizio

Una volta creato e configurato l’unit file, è tempo di metterlo in funzione.

Ricaricare la configurazione di systemd: Dopo aver creato o modificato un unit file, systemd deve essere informato dei cambiamenti. Questo si fa con daemon-reload:

sudo systemctl daemon-reload

Verificare la sintassi: È sempre una buona idea verificare che non ci siano errori di sintassi nel file prima di tentare l’avvio.

sudo systemd-analyze verify /etc/systemd/system/app.service

Se non restituisce output, il file è sintatticamente corretto.

Abilitare il servizio: enable crea un link simbolico dal file del servizio alla directory multi-user.target.wants/ (o simile), assicurando che il servizio venga avviato automaticamente al boot. L’opzione --now lo avvia immediatamente.

sudo systemctl enable --now app

Verificare lo stato del servizio: Per controllare se il servizio è attivo, in esecuzione e senza errori, usa status:

systemctl status app

Dovresti vedere Active: active (running) e le ultime righe di log.

Leggere i log del servizio

Quando un servizio non funziona come previsto, i log sono la tua risorsa più preziosa. systemd centralizza i log tramite journald, accessibili con il comando journalctl.

Per visualizzare i log di un servizio specifico:

journalctl -u app

Per visualizzare i log in tempo reale (come tail -f):

journalctl -u app -f

Questo ti permette di monitorare l’output del tuo servizio e diagnosticare eventuali problemi in tempo reale. Puoi anche filtrare per data, priorità e altre opzioni. Per maggiori dettagli, consulta la documentazione ufficiale di systemd.

Errori comuni e troubleshooting

Anche con la migliore configurazione, possono verificarsi errori. Ecco alcuni dei più comuni e come risolverli:

Servizio non trovato: systemctl status app restituisce Unit app.service could not be found.. Questo di solito significa che il file app.service non è nella directory corretta o che systemctl daemon-reload non è stato eseguito dopo la creazione/modifica del file.
Permessi errati: Se il servizio non riesce ad avviare e journalctl mostra errori di

Fonti

[Systemd: 10 comandi essenziali che ogni SysAdmin deve conoscere]
[Come gestire i servizi Linux con systemctl: guida completa]
[Ansible: gestire variabili d’ambiente e file di configurazione]
documentazione ufficiale di systemd