1,203 26/03/2026 07/04/2026 7 min

Quando una directory sotto /run o /var/run sparisce dopo il reboot, il sintomo sembra banale ma in produzione può bloccare socket, PID file, cache temporanee e servizi dipendenti. Il caso tipico è questo: un’app parte bene dopo il deploy, poi al riavvio il servizio fallisce con errori come No such file or directory, Permission denied o Failed to open PID file. In molti ambienti il colpevole non è l’applicazione, ma una regola di systemd-tmpfiles mancante, errata o applicata troppo tardi.

Questo articolo non spiega l’installazione base di systemd: parte da un incidente reale e va dritto su diagnosi, ripristino e rollback. L’obiettivo è capire cosa controllare quando una directory temporanea non viene ricreata al boot, come distinguere un problema di tmpfiles da un problema di permessi o di ordine di avvio, e come tornare rapidamente a uno stato stabile senza peggiorare il guasto.

Diagnosi probabile

La causa più frequente è una di queste tre:

  1. Regola tmpfiles assente o sbagliata: la directory non è definita in /etc/tmpfiles.d/*.conf o nella configurazione fornita dal pacchetto.
  2. Permessi o ownership non compatibili: la directory viene creata, ma il servizio non può scriverci perché owner, gruppo o mode non corrispondono a quanto atteso.
  3. Ordine di avvio errato: il servizio parte prima che systemd-tmpfiles-setup.service abbia creato il percorso, oppure il servizio usa una directory sotto /run senza dipendere correttamente dal setup iniziale.

Un dettaglio sottovalutato: /run è volatile. Dopo il reboot viene svuotata e ricreata da systemd. Se il servizio si appoggia a file temporanei, socket o directory runtime, non basta che esistano “durante il deploy”: devono essere ricreati automaticamente a ogni avvio.

Il problema si vede spesso dopo un aggiornamento, un cambio di pacchetto o un rollback parziale. Per esempio, il pacchetto precedente forniva una regola tmpfiles, quello nuovo no; oppure una modifica manuale in /run ha mascherato il difetto fino al riavvio successivo.

Verifiche immediate

Prima di cambiare file, conviene raccogliere prove. Le verifiche qui sotto sono rapide e mostrano subito se il guasto è in tmpfiles, nei permessi o nell’ordine di boot.

  1. Controlla i log del servizio con:
journalctl -u nome-servizio -b --no-pager

Esito atteso: errori riferiti al percorso mancante, a socket non creati o a permessi negati. Se vedi un fallimento prima ancora che l’app inizializzi, il problema è spesso esterno all’app stessa.

  1. Verifica lo stato di tmpfiles con:
systemctl status systemd-tmpfiles-setup.service

Esito atteso: servizio active (exited) senza errori. Se è in failed, i log di boot contengono quasi sempre il motivo.

  1. Simula l’applicazione delle regole con:
systemd-tmpfiles --create --boot

Scopo del controllo: vedere se le regole possono essere applicate senza errori. Se il comando segnala path già esistenti con ownership diversa, un file di configurazione sta imponendo valori incompatibili oppure una directory è stata creata manualmente con attributi sbagliati.

  1. Controlla la regola effettiva con:
grep -R "app.tmp\|nome-percorso" /etc/tmpfiles.d /usr/lib/tmpfiles.d 2>/dev/null

Esito atteso: una riga che definisce il path con tipo, mode, owner e gruppo. Se non trovi nulla, il file di regola non esiste o è stato rimosso dal pacchetto.

  1. Verifica il servizio che usa la directory con:
systemctl cat nome-servizio

Scopo del controllo: capire se il servizio ha dipendenze correttamente espresse, per esempio After=systemd-tmpfiles-setup.service o una configurazione più adatta a socket e runtime directory.

Soluzione consigliata passo-passo

La correzione più sicura è ripristinare la creazione automatica della directory, poi validare che il servizio parta senza interventi manuali.

  1. Fai un backup della regola esistente se la trovi in una directory locale:
sudo cp -a /etc/tmpfiles.d/nome-servizio.conf /etc/tmpfiles.d/nome-servizio.conf.bak

Questo ti permette di tornare indietro rapidamente se la sintassi o i permessi risultano errati.

  1. Crea o correggi la regola tmpfiles in /etc/tmpfiles.d/nome-servizio.conf. Un esempio tipico:
d /run/nome-servizio 0755 root root -

Se la directory deve appartenere a un utente dedicato, usa owner e gruppo corretti, per esempio:

d /run/nome-servizio 0750 appuser appgroup -

Scopo del controllo: assicurare che la directory venga creata a ogni boot con i permessi previsti.

  1. Applica la regola subito senza aspettare il reboot:
sudo systemd-tmpfiles --create /etc/tmpfiles.d/nome-servizio.conf

Esito atteso: nessun errore. Verifica poi con:

ls -ld /run/nome-servizio

Condizione di successo: owner, gruppo e mode corrispondono alla regola.

  1. Riavvia solo il servizio coinvolto:
sudo systemctl restart nome-servizio

Se il servizio ora parte, la diagnosi è confermata: la directory runtime non veniva preparata correttamente al boot o i permessi erano incoerenti.

  1. Se il servizio parte troppo presto, correggi l’unità con un override minimale:
sudo systemctl edit nome-servizio

Nel file aperto puoi aggiungere, se serve davvero, una dipendenza prudente:

[Unit]
After=systemd-tmpfiles-setup.service
Requires=systemd-tmpfiles-setup.service

Usa questa modifica solo se hai verificato che il problema è l’ordine di avvio. Non è sempre necessaria, e forzarla senza motivo può introdurre dipendenze inutili.

  1. Ricarica systemd e verifica la catena di boot:
sudo systemctl daemon-reload
systemctl show -p After -p Requires nome-servizio

Esito atteso: la dipendenza compare solo se l’hai introdotta. Se non compare, controlla che l’override sia stato salvato nel file corretto.

Quando la directory è sotto /var/lib e non sotto /run

Se il percorso non è temporaneo ma persistente, non usare una regola pensata per runtime volatile. In quel caso il problema può essere diverso: un pacchetto ha cambiato owner, un restore da backup ha alterato i permessi oppure una policy di SELinux o AppArmor blocca l’accesso.

Per distinguere i casi, osserva la posizione del path:

  • /run: si ricrea a ogni boot, quindi tmpfiles è spesso la soluzione giusta.
  • /var/lib o /var/log: il problema è più spesso in permessi, contesto di sicurezza o migrazione incompleta.

Se hai un dubbio, non spostare i dati a mano in una nuova directory senza prima verificare cosa si aspetta il servizio. Un fix “veloce” può rompere backup, upgrade o script di manutenzione.

Quando il guasto nasce dopo un aggiornamento

È comune che un aggiornamento del pacchetto rimuova una regola tmpfiles o ne cambi i parametri. In questo caso la diagnosi migliore è confrontare il pacchetto installato con i file locali:

rpm -qc nome-pacchetto 2>/dev/null || dpkg -L nome-pacchetto | grep tmpfiles

Scopo del controllo: capire se la regola era fornita dal pacchetto e se è stata sovrascritta localmente. Se il file è mancante dopo l’update, il ripristino più pulito è reinstallare il pacchetto o estrarre la regola corretta dalla release precedente, non inventare un path “a occhio”.

Controlli finali / rollback

Dopo il fix, verifica che il problema non ricompaia al riavvio, perché con tmpfiles molti guasti si vedono solo al boot successivo.

  1. Controlla il boot corrente e quello precedente con:
journalctl -b -u systemd-tmpfiles-setup.service --no-pager
journalctl -b -1 -u nome-servizio --no-pager

Condizione di successo: nessun errore di creazione path e nessun No such file or directory sul servizio.

  1. Esegui un test di riavvio controllato se sei in finestra di manutenzione. Dopo il reboot, verifica subito:
ls -ld /run/nome-servizio
systemctl status nome-servizio

Esito atteso: directory presente con attributi corretti e servizio attivo senza interventi manuali.

  1. Rollback rapido se la nuova regola introduce effetti collaterali: ripristina il backup della configurazione, rimuovi l’override dell’unità e rilancia systemd-tmpfiles --create. Se il servizio tornava funzionante prima della modifica, questa è la via più sicura per tornare allo stato precedente.

Se la causa resta ambigua, la priorità è stabilizzare il servizio con la regola minima necessaria e poi approfondire. In produzione è meglio una directory creata correttamente con permessi essenziali che una dipendenza eccessiva o una modifica strutturale fatta senza conferma.

In sintesi, quando una directory runtime sparisce o cambia comportamento dopo il reboot, non partire dal riavvio del servizio “a tentativi”. Prima verifica logs, regole tmpfiles e ordine di boot; poi applica la correzione più piccola possibile; infine conferma il risultato con un reboot di prova. È questo passaggio, spesso trascurato, che separa un fix temporaneo da un ripristino davvero affidabile.