Perché / var / run è stato migrato su / run?

L'intento è ridurre il numero di file system tmpfs . In data 11.04, ci sono sistemi di file tmpfs separati a /var/lock , /var/run e /dev/shm . Se queste directory si trovassero tutte in una singola directory principale, sarebbe necessario un solo tmpfs . Fornisce anche una posizione ovvia per ulteriori dati sullo stato di runtime che non dovrebbero persistere nei riavvii.

A meno che la tua applicazione non dipenda dai percorsi canonici dei file, la tua applicazione dovrebbe essere eseguita senza modifiche poiché le vecchie posizioni saranno collegate simbolicamente a quelle nuove. Le politiche di AppArmor sono un caso che dipende dai nomi dei percorsi reali, motivo per cui è stato menzionato in modo specifico.

I seguenti collegamenti dovrebbero aiutare a spiegare la logica:

• link
• link
• link
• link

1. /run è una nuova posizione di tmpfs di distribuzione incrociata per la memorizzazione di file di stato transitori, ovvero file contenenti informazioni di runtime che possono o non devono essere scritte all'inizio del processo di avvio e che non richiedono preservando attraverso i riavvii.

   Rendere la directory /run disponibile ci avvicina di un passo al punto in cui è possibile utilizzare il sistema normalmente con il filesystem di root montato in sola lettura, senza richiedere soluzioni alternative come aufs/unionfs overlay.

   /run sostituisce diverse posizioni esistenti descritte nello standard della gerarchia del filesystem:

   • /var/run → /run
   • /var/lock → /run/lock
   • /dev/shm → /run/shm [attualmente solo Debian pianifica di farlo]
   • /tmp → /run/tmp [opzionale; attualmente solo Debian prevede di offrire questo]

   • /run sostituisce anche altre posizioni che sono state utilizzate per i file temporanei:

   • /lib/init/rw → /run

   • /dev/.* → /run/*
   • /dev/shm/* → /run/*
   • file scrivibili sotto /etc → /run/*

   (quindi probabilmente puoi aspettarti che si spostino anche loro).

   Fonte: obiettivi di rilascio debian

2. Consiglierei di creare una parte nel tuo software in cui imposti queste directory in variabili, cambia il tuo codice per usare queste variabili e poi altera le variabili in base al sistema su cui è usato (ma scommetto che sapevi già).

Da quello che ho letto, questa è stata la spiegazione originale del perché / run è stata introdotta. link

Nota: poiché / run introduce, piccole configurazioni potrebbero avere problemi. Il mio server Ubuntu è 256Mo RAM e / run è di default impostato su 49Mo.
All'avvio, riempie il filesystem fino alla pienezza.
Apportare modifiche in fstab non funziona per aumentare le dimensioni di esecuzione / temps. Né le altre procedure che ho trovato su gg.
Ho trovato la soluzione da aggiungere nello script init: /etc/rc.local la riga     %codice% da estendere all'avvio. (L'85M è per il mio conf.)

Non dovresti inserire hardcode in nessuno di questi percorsi /run !

• Utilizza /var/run , perché un link simbolico sarà presente a /run se applicabile
• /var/lock è uguale a sopra
• Non hardcode /dev/shm mai, usa sempre shm_open etc (l'API posix)