155 30/03/2026 07/04/2026 5 min

Diagnosi probabile

Quando un servizio systemd non si avvia, le cause più frequenti sono poche e quasi sempre verificabili in pochi minuti: unità configurata male, file di configurazione del servizio con errore, porta già occupata, dipendenze mancanti, permessi errati oppure applicazione che esce subito con codice di errore. In produzione, la priorità non è “sistemare tutto”, ma capire se il problema è nel servizio, nella configurazione o nell’ambiente che lo circonda.

Il principio giusto è questo: prima si guarda lo stato reale del servizio e l’ultimo errore utile, poi si controlla la configurazione che lo governa, infine si applica il fix più piccolo possibile. Se il servizio è critico, vale anche una regola pratica: non cambiare tre cose insieme, perché poi non sai quale ha risolto o peggiorato il problema.

Verifiche immediate

Prima di toccare la configurazione, raccogli queste evidenze. Sono controlli rapidi e ti dicono subito in che direzione andare.

  1. Controlla lo stato del servizio e l’errore sintetico:

    systemctl status nome-servizio --no-pager

    Esito atteso: vedi se il servizio è failed, se si ferma subito, se mostra un codice di uscita o un messaggio tipo permission denied, address already in use, configuration file error.

  2. Leggi i log recenti del servizio:

    journalctl -u nome-servizio -b --no-pager -n 100

    Esito atteso: trovi la riga esatta del fallimento. Questo è spesso il punto decisivo, perché il journal mostra l’errore vero, non solo il riassunto.

  3. Verifica se la porta o la risorsa è già occupata, se il servizio espone una rete:

    ss -ltnp | grep -E ':80|:443|:3306|:25|:587'

    Esito atteso: se compare un altro processo sulla stessa porta, hai già una causa probabile. Sostituisci la porta con quella del tuo servizio se necessario.

Se il servizio non è di rete, il controllo equivalente è sui file, sui mount o sulle dipendenze: spesso il problema reale non è il demone, ma un percorso non trovato o un disco non montato.

Soluzione consigliata passo-passo

  1. Identifica la causa più probabile dal log e intervieni solo su quella. Esempi pratici:

    • se trovi configuration error, apri il file indicato e correggi la sintassi;
    • se trovi permission denied, controlla owner e permessi del file o della directory usata dal servizio;
    • se trovi address already in use, libera la porta oppure cambia la porta del servizio;
    • se trovi un percorso mancante, verifica che il mount o il file esista davvero.

    Questa è la parte più importante: non fare un restart alla cieca finché non hai un indizio concreto.

  2. Se hai modificato un file di configurazione, fai prima un backup e poi correggi. Esempio generico per un file di unità o di configurazione:

    cp /percorso/file.conf /percorso/file.conf.bak

    Esito atteso: hai una copia immediatamente ripristinabile se la modifica introduce un nuovo errore.

  3. Dopo la correzione, ricarica systemd se hai toccato l’unità o un override:

    systemctl daemon-reload

    Esito atteso: systemd prende la nuova definizione senza dover riavviare tutto il server.

  4. Riavvia il servizio in modo controllato:

    systemctl restart nome-servizio

    Esito atteso: il comando termina senza errore e il servizio passa a active (running).

  5. Verifica subito dopo il riavvio:

    systemctl status nome-servizio --no-pager

    Esito atteso: lo stato è attivo e non compaiono nuovi errori. Se il servizio torna failed, torna al journal e cerca il nuovo messaggio, non il vecchio.

  6. Se il servizio continua a non partire, prova un controllo di validazione specifico dell’applicazione, quando esiste. Alcuni esempi tipici:

    • nginx: nginx -t per testare la configurazione;
    • php-fpm: php-fpm -t o il test equivalente della tua versione;
    • mysql/mariadb: verifica spazio disco, permessi e log errori del database;
    • postgresql: controlla log e ownership della directory dati.

    Esito atteso: il test di configurazione fallisce o passa con un messaggio chiaro, utile per il fix mirato.

  7. Se il problema è una dipendenza non pronta, controlla l’ordine di avvio e i prerequisiti. In alcuni casi conviene aggiungere un After= o un controllo di disponibilità, ma solo dopo aver confermato che la dipendenza è davvero il collo di bottiglia. Se il servizio dipende da rete, database o mount, verifica che questi siano attivi prima del demone.

Se vuoi ridurre i tempi di diagnosi, lavora sempre in questa sequenza mentale: stato, log, causa, fix minimo, verifica. È il modo più veloce per evitare interventi inutili.

Controlli finali / rollback

  1. Controllo finale minimo: assicurati che il servizio sia realmente operativo e non solo avviato per pochi secondi.

    systemctl is-active nome-servizio

    Esito atteso: risposta active. Se torna inactive o failed, il problema non è risolto.

  2. Se il servizio espone una porta, verifica che sia in ascolto e raggiungibile localmente:

    ss -ltnp | grep nome-servizio

    Esito atteso: il processo corretto ascolta sulla porta prevista.

  3. Se la modifica non ha risolto o ha peggiorato la situazione, fai rollback ripristinando il file salvato prima del cambio e ricarica systemd:

    cp /percorso/file.conf.bak /percorso/file.conf
systemctl daemon-reload
systemctl restart nome-servizio

    Condizione di rollback: usalo se dopo la modifica compaiono nuovi errori o il servizio prima funzionava e poi ha smesso di farlo.

  4. Conserva l’ultimo messaggio del journal come riferimento. Se il servizio fallisce ancora, la prossima iterazione deve partire da quel log, non da ipotesi generiche.

In pratica, il metodo più affidabile è questo: raccogli un errore reale, correggi una sola causa alla volta, verifica subito il risultato e tieni sempre pronto un rollback semplice. Su server Linux questo approccio fa risparmiare tempo e riduce molto il rischio di introdurre nuovi problemi.

Assunzione operativa: i comandi sono pensati per sistemi con systemd, tipici di Debian, Ubuntu, AlmaLinux, Rocky Linux e CentOS recenti.