Pourquoi / var / run a-t-il été migré vers / run?

66

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).

  • Je code ces chemins dans mes applications, pourquoi cette modification est-elle apportée à Oneiric?
  • Que puis-je faire pour rendre mes applications compatibles en amont et en aval? Existe-t-il un meilleur moyen de vérifier d’abord l’existence de /run, puis /var/run?
filesystem Lekensteyn
la source

Réponses:

58

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:

James Henstridge
la source
36

  1. /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/*
    • fichiers inscriptibles sous /etc→/run/*

    (donc vous pouvez probablement vous attendre à ce qu'ils bougent aussi).

    Source: objectifs de publication de Debian

  2. 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à).

Rinzwind
la source
1
Que voulez-vous dire des fichiers en écriture sous /etc. Ceux-ci doivent tous persister après le redémarrage, non? C'est juste des fichiers de conf génériques.
Evan Carroll le
6
Oh je vois. Trois fichiers sous /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.
Evan Carroll le
5

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/

Gotunandan
la source
8
Bien que cela puisse théoriquement répondre à la question, il serait préférable d’inclure ici les parties essentielles de la réponse et de fournir le lien à titre de référence.
Stefano Palazzo
3

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.)

korrident
la source
2

Vous ne devriez pas coder en dur aucun de ces /runchemins!

  • Utilisez /var/run, car un lien symbolique sera en place pour le /runcas échéant
  • /var/lock est le même que ci-dessus
  • Ne /dev/shmjamais coder en dur , utilisez toujours shm_openetc (l'API posix)
Ramlök
la source