systemd: verifica `daemon-reload` e `tmpfiles` dopo deploy

Dopo un deploy su una VPS o su un server dedicato, i problemi più fastidiosi non sono sempre nell’applicazione: spesso arrivano da systemd, journald o dalle regole di tmpfiles. Se il servizio non parte, i log non si scrivono o una directory attesa sparisce al reboot, conviene fare subito una verifica breve e ripetibile.

Diagnosi probabile

La causa più comune è una combinazione di questi fattori:

1. unità systemd aggiornata ma non ricaricata con daemon-reload;
2. permessi o directory runtime create male da tmpfiles.d;
3. journald pieno, inattivo o non scrivibile dal servizio;
4. override locali che cambiano l’ambiente del servizio dopo il deploy.

Verifiche immediate

1. Controlla lo stato del servizio e l’ultimo errore utile:
   systemctl status nome-servizio --no-pager
   Esito atteso: active (running) oppure un messaggio chiaro sul fallimento.
2. Leggi i log recenti del servizio:
   journalctl -u nome-servizio -b --no-pager -n 50
   Esito atteso: nessun errore di permessi, path mancanti o bind falliti.
3. Verifica se systemd ha caricato davvero la nuova unità:
   systemctl cat nome-servizio
   Esito atteso: il contenuto mostrato deve includere le ultime modifiche del deploy.
4. Controlla eventuali regole tmpfiles legate al servizio:
   systemd-tmpfiles --cat-config | grep -i nome-servizio
   Esito atteso: una regola coerente per directory, socket o file runtime.
5. Se il servizio usa directory temporanee o runtime, verifica che esistano e abbiano i permessi giusti:
   ls -ld /run/nome-servizio /var/lib/nome-servizio
   Esito atteso: owner e permessi compatibili con l’utente del servizio.

Soluzione consigliata passo-passo

1. Ricarica systemd prima di riavviare il servizio:
   systemctl daemon-reload
   Serve quando hai modificato unità, drop-in o file in /etc/systemd/system/.
2. Applica le regole tmpfiles, se hai aggiunto o cambiato directory/file runtime:
   systemd-tmpfiles --create
   Esito atteso: creazione delle risorse mancanti senza errori.
3. Riavvia il servizio e verifica subito il risultato:
   systemctl restart nome-servizio
   poi
   systemctl is-active nome-servizio
   Esito atteso: active.
4. Se il servizio continua a fallire, isola il problema con il log del boot corrente:
   journalctl -u nome-servizio -b -p warning..alert --no-pager
   Scopo: vedere solo i messaggi davvero rilevanti.
5. Se usi un file di override, ricontrolla che non abbia sovrascritto WorkingDirectory, User o Environment in modo incoerente con il deploy.

Controlli finali / rollback

1. Verifica che il servizio resti su dopo un secondo restart:
   systemctl restart nome-servizio && systemctl is-active nome-servizio
   Condizione di successo: stato stabile e log puliti.
2. Controlla che journald stia ricevendo nuovi eventi del servizio:
   journalctl -u nome-servizio -b --no-pager -n 5
   Esito atteso: nuove righe coerenti con l’avvio.
3. Se il problema è nato dopo una modifica, fai rollback ripristinando il vecchio unit file o il vecchio drop-in e ripeti systemctl daemon-reload prima del riavvio.
4. Se hai toccato tmpfiles.d e il servizio si è rotto, rimuovi la regola introdotta, poi riesegui systemd-tmpfiles --create solo dopo aver verificato il percorso corretto.

Checklist minima da tenere dopo ogni deploy: ricarica unità, crea risorse tmpfiles, controlla i log, verifica lo stato attivo, prova un riavvio rapido.