1 de abril de 2011

¿Qué hace ese directorio /run en mi sistema?

Parece ser que todo sistema Linux va a incorporar un directorio "run" a su directorio raiz, o sea, un /run. La primera reacción de muchos Linuxeros va a ser empezar a afilar los cuchillos, pero pueden estar tranquilos: En realidad es una buena idea, y nos librará de varios artilugios oscuros de los que hasta ahora no éramos demasiado conscientes (nota: este post viene a ser una asimilación de esta explicación de Lennart Poettering).

En el proceso de inicio temprano de un sistema Linux típico suelen ejecutarse varios programas -udev, mdadm, systemd, scripts varios- que necesitan almacenar datos de la misma categoría que los que hay en /var/run. Sin embargo se va a tardar un rato en montarlo, ya que podría estar ubicado incluso en un disco distinto a "/", recordemos que es "tradición" unixera considerar a /var un directorio de datos altamente "var-iables", con mucha actividad, idóneo para ubicarse en un disco rápido (por ejemplo un RAID, precisamente el tipo de cosas que necesita mdadm).

Pero estos programas de inicio necesitan guardar esos datos. ¿Dónde hacerlo, puesto que no se puede asumir que guardalos en /var/run es seguro? La cosa no está nada clara, y la convención no oficial ha sido usar como almacen a /dev, que se montado sobre tmpfs desde el principio. En mi sistema, dentro de /dev tengo los siguientes directorios de este tipo: .initramfs, .mdadm, .mount, .systemd, .udev.

Sin embargo, ese no es el sitio apropiado para guardar esos datos y supone una duplicación mal hecha de /var/run. En otras palabras, es un hack. Así que, en un ejemplo de unidad que raras veces suele verse en este mundo, se han unido todas las distros principales para decidir que en realidad /var/run no pertenece a /var: /var es para "datos persistentes que cambian mucho" y /var/run es para "datos volátiles que cambian mucho". Asi que se ha llegado a la decisión unánime de que es necesario un nuevo directorio raiz "/run", montado sobre tmpfs; /var/run por su parte se convertirá en un enlace a /run, y /var/lock (que ya de paso sufre los mismos problemas) lo será a /run/lock.

De ese modo, todas las aplicaciones, tanto las que se inician al principio del sistema como las menos tempraneras, utilizan el mismo directorio montado sobre tmpfs, ya no es necesario meter directorios ocultos en /dev, y /var/run y /var/lock pasarán a compartir el mismo tmpfs.

A la vista de los argumentos es indudable que es una decisión buena, pero no olvidemos que existen fuertes ultraconservadurismos en el mundo Unix/Linux que consideran la introducción de algo así como algo que enturbia las prístinas aguas del Verdadero Diseño Unixero y corroe la pureza de nuestros espíritus. A Lennart Poettering le tocará, una vez más, cargar con las culpas de querer mejorar las cosas.

11 comentarios:

  1. Me parece una gran idea. Yo ya uso /var/run como tmpfs.

    Y bueno... mente abierta, al menos con las buenas ideas.

    Por cierto, no es april fool's day, verdad?

    ResponderEliminar
  2. Espero que no sea April Fool's, porque el original es de ayer y sería demasiado forzado xD

    Además de que parece una buena idea.

    ResponderEliminar
  3. «/var/run será un enlace a /var/run»
    Me ha costado decidirme a comentar, pero en el original he visto que pone «/run is now a tmpfs, and /var/run is bind mounted to it.» Por tanto supongo que querías decir «/var/run será un enlace a /run». ¿Tal vez al revés? No sé, estoy confuso. XD
    De rebote he descubierto que el original tampoco es tan difícil de entender como suponía, además acabo de aprender un par de cosas que no sabía.
    Una duda, ¿un "bind mount" se traduce al castellano como un enlace? ¿Entre eso y el symlink no se presta a confusión? Igual no es el sitio apropiado para preguntar, pero gracias igualmente.

    ResponderEliminar
  4. Un "bind mount" es tener un contenido accesible desde todos los lugares que necesites del filesystem. No es como un enlace, de hecho, en GFS2, por ejemplo, no permiten -no se soportan enlaces- y todo ha de hacerse con mount --bind.

    ResponderEliminar
  5. Espero que Linus no se haya puesto "farruco" con Lennart como en el parche del sched ... xDD

    ResponderEliminar
  6. Dokan: Tienes razón, la frase era absurda. Y si, el original no tiene nada de incomprensible.

    ResponderEliminar
  7. Ademas mount bind es mucho mas util, porque acepta el autocompletado mejor y no se hace un lio con las rutas como le pasa a los symlinks entre filesystems.

    Por cierto, la noticia muy interesante como siempre. :)

    Una joya de blog la verdad. :)

    ResponderEliminar
  8. Si se lo cuento a mis amigos, seguro que no me creen. Dios, estas noticias te alegran el día, primero por que la mayoría ya hace hack (guarrerías) y los monta sobre tmpfs, después, por que se pongan de acuerdo en algo varias distribuciones.
    Felicitaciones por el blog. Das información útil, gracias.

    ResponderEliminar
  9. Y hablando de la organización del sistema de archivos de Linux ¿qué opinas del FHS (http://es.wikipedia.org/wiki/FHS)?

    No soy quién para decirte o pedirte qué tienes que escribir, pero me gustaría ver una entrada sobre este tema y tu opinión sobre el mismo.

    Un saludo.

    ResponderEliminar
  10. Anónimo9:12 a. m.

    oleeeee no me he enterado de nada

    ResponderEliminar
  11. Anónimo9:13 a. m.

    huele a friki

    ResponderEliminar