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

Dalla panoramica tecnica di Ubuntu 11.10 Oneiric :

Ubuntu 11.10 è migrata distanti /var/run, /var/locke /dev/shmora usa /run, /run/locke /run/shminvece (rispettivamente).

• Ho codificato questi percorsi nelle mie applicazioni, perché questa modifica è stata apportata a Oneiric?
• Cosa posso fare per rendere le mie applicazioni compatibili con le versioni precedenti e successive? Esiste un modo migliore se non quello di verificare prima l'esistenza di /rune poi /var/run?

L'intento è ridurre il numero di tmpfsfile system. Sulla 11.04, ci sono separati tmpfsi file system a /var/lock, /var/rune /dev/shm. Se tutte queste directory si trovassero tutte in una singola directory principale, tmpfssarebbe necessaria solo una singola directory . Fornisce inoltre una posizione ovvia per ulteriori dati sullo stato di runtime che non devono persistere al riavvio.

A meno che l'applicazione non dipenda da percorsi canonici di file, l'applicazione deve essere eseguita senza modifiche poiché le posizioni precedenti verranno collegate a quelle nuove. I criteri 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:

• http://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html
• https://bugs.linuxfoundation.org/show_bug.cgi?id=718
• https://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-May/000061.html
• http://wiki.debian.org/ReleaseGoals/RunDirectory

1. /run è una nuova posizione tmpfs di distribuzione incrociata per l'archiviazione 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 la conservazione durante i riavvii.

   Rendere /rundisponibile la directory ci avvicina al punto in cui è possibile utilizzare il sistema normalmente con il filesystem di root montato in sola lettura, senza richiedere ingombranti soluzioni come aufs/unionfssovrapposizioni.

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

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

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

   • /lib/init/rw → /run

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

   (quindi probabilmente puoi aspettarti che anche questi si muovano).

   Fonte: obiettivi di rilascio debian

2. Consiglierei di creare una parte nel vostro software in cui si impostano queste directory in variabili, si cambia il codice per utilizzare queste variabili e quindi si alterano le variabili in base al sistema su cui è utilizzato (ma scommetto che lo sapevate già).

Da quello che ho letto, questa era la spiegazione originale data sul perché / run è stato introdotto. http://lwn.net/Articles/436012/

Nota: dall'introduzione / esecuzione, piccole configurazioni potrebbero causare problemi. Il mio server Ubuntu è 256Mo di RAM e / run è impostato di default su 49Mo.
All'avvio, riempie il filesystem fino alla pienezza.
Apportare modifiche in fstab non funziona per aumentare tempfs / run size. Né altre procedure che ho trovato su gg.
Ho trovato la soluzione da aggiungere nello script init: /etc/rc.localla linea mount -t tmpfs tmpfs /run -o remount,size=85M da estendere all'avvio. (L'85M è per la mia conf.)

Non dovresti hardcodificare nessuno di questi /runpercorsi!

• Utilizzare /var/run, poiché sarà presente un collegamento simbolico a /runse applicabile
• /var/lock è lo stesso di cui sopra
• Non hardcode /dev/shmmai, usa sempre shm_openecc (l'API posix)