Dans la présentation technique d’Ubuntu 11.10 Oneiric :
Ubuntu 11.10 a migré depuis
/var/run,/var/locket/dev/shmutilise maintenant/run,/run/locket à la/run/shmplace (respectivement).
/run, puis /var/run?Réponses:
Le but est de réduire le nombre de tmpfssystèmes de fichiers. Le 11.04, il existe des tmpfssystèmes de fichiers distincts à /var/lock, /var/runet /dev/shm. Si ces répertoires se trouvaient tous dans un seul répertoire parent, un seul tmpfsserait nécessaire. Il fournit également un emplacement évident pour d'autres données d'état d'exécution qui ne devraient pas persister après les redémarrages.
À moins que votre application ne dépende des chemins d'accès canoniques des fichiers, votre application doit s'exécuter sans modification, car les anciens emplacements seront liés symboliquement aux nouveaux. Les stratégies AppArmor sont un cas qui dépend des noms de chemin réels, raison pour laquelle cela a été mentionné spécifiquement.
Les liens suivants devraient aider à expliquer le raisonnement:
/run est un nouvel emplacement tmpfs pour le stockage des fichiers d’états transitoires, c’est-à-dire des fichiers contenant des informations d’exécution qui peuvent ou non avoir besoin d’être écrites tôt dans le processus d’amorçage et qui ne nécessitent pas de préservation après les redémarrages.
Rendre le /runrépertoire disponible nous rapproche du point où il est possible d'utiliser le système normalement avec le système de fichiers racine monté en lecture seule, sans nécessiter de solution de rechange maladroite telle que des aufs/unionfssuperpositions.
/run remplace plusieurs emplacements existants décrits dans la norme de hiérarchie des systèmes de fichiers:
/var/run → /run/var/lock → /run/lock/dev/shm→ /run/shm[Actuellement, seul Debian a l'intention de le faire]/tmp→ /run/tmp[facultatif; actuellement, seule Debian a l’intention de l’offrir]/run remplace également certains autres emplacements utilisés pour les fichiers transitoires:
/lib/init/rw → /run
/dev/.* → /run/*/dev/shm/* → /run/*/etc→/run/*(donc vous pouvez probablement vous attendre à ce qu'ils bougent aussi).
Je conseillerais de créer une partie de votre logiciel dans laquelle vous définissez ces répertoires dans des variables, modifiez votre code pour utiliser ces variables, puis modifiez les variables en fonction du système sur lequel il est utilisé (mais je parie que vous le saviez déjà).
/etc, /etc/lvm/cache/ /etc/mtab /etc/network/run/ifstateet bientôt /etc/adjtime. Je suppose que c'était mauvais pour eux d'être /etcau début.
D'après ce que j'ai lu, c'était l'explication originale donnée pour expliquer pourquoi / run avait été introduit. http://lwn.net/Articles/436012/
Remarque: depuis / run introduction, les petites configurations risquent de poser des problèmes. Mon serveur Ubuntu est doté de 256 Mo de RAM et / run est défini par défaut sur 49Mo.
Au démarrage, il remplit le système de fichiers jusqu'à saturation.
Faire des changements dans fstab ne fonctionne pas pour augmenter la taille de tempfs / run. Les autres procédures que j'ai trouvées sur gg non plus.
J'ai trouvé la solution à ajouter au script d'initialisation: /etc/rc.localla ligne
mount -t tmpfs tmpfs /run -o remount,size=85M
s'étend au démarrage. (Le 85M est pour mon conf.)
/etc. Ceux-ci doivent tous persister après le redémarrage, non? C'est juste des fichiers de conf génériques.