¿Por qué se ha migrado / var / run a / run?

Desde la descripción técnica de Ubuntu 11.10 Oneiric :

Ubuntu 11.10 ha migrado lejos de /var/run, /var/locky /dev/shmy ahora utiliza /run, /run/locky /run/shmen lugar (respectivamente).

• Codifico estas rutas en mis aplicaciones, ¿por qué se realiza este cambio en Oneiric?
• ¿Qué puedo hacer para que mis aplicaciones sean compatibles con versiones anteriores y posteriores? ¿Hay una mejor manera que no sea verificar primero la existencia de /run, y luego /var/run?

La intención es reducir la cantidad de tmpfssistemas de archivos. El 11.04, hay tmpfssistemas de archivos separados en /var/lock, /var/runy /dev/shm. Si estos directorios estuvieran todos bajo un solo directorio principal, entonces solo tmpfsse necesitaría uno. También proporciona una ubicación obvia para más datos de estado de tiempo de ejecución que no deberían persistir durante los reinicios.

A menos que su aplicación dependa de rutas canónicas de archivos, su aplicación debería ejecutarse sin modificaciones ya que las ubicaciones antiguas se vincularán a las nuevas. Las políticas de AppArmor son un caso que depende de los nombres de ruta reales, por lo que se mencionó específicamente.

Los siguientes enlaces deberían ayudar a explicar la justificación:

• 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 es una nueva ubicación tmpfs de distribución cruzada para el almacenamiento de archivos de estado transitorios, es decir, archivos que contienen información de tiempo de ejecución que puede o no necesitar ser escrita al principio del proceso de arranque y que no requiere preservación entre reinicios.

   Hacer que el /rundirectorio esté disponible nos lleva un paso más cerca del punto en el que es posible usar el sistema normalmente con el sistema de archivos raíz montado de solo lectura, sin requerir soluciones torpes como aufs/unionfssuperposiciones.

   /run reemplaza varias ubicaciones existentes descritas en el Estándar de jerarquía del sistema de archivos:

   • /var/run → /run
   • /var/lock → /run/lock
   • /dev/shm→ /run/shm[actualmente solo Debian planea hacer esto]
   • /tmp→ /run/tmp[opcional; actualmente solo Debian planea ofrecer esto]

   • /run También reemplaza algunas otras ubicaciones que se han utilizado para archivos transitorios:

   • /lib/init/rw → /run

   • /dev/.* → /run/*
   • /dev/shm/* → /run/*
   • archivos grabables bajo /etc→/run/*

   (por lo que probablemente pueda esperar que estos se muevan también).

   Fuente: objetivos de lanzamiento de Debian

2. Yo recomendaría crear una parte en su software donde configure estos directorios en variables, cambie su código para usar estas variables y luego modifique las variables según el sistema en el que se usa (pero apuesto a que ya lo sabía).

Por lo que he leído, esta fue la explicación original de por qué se introdujo / ejecutar. http://lwn.net/Articles/436012/

Nota: desde la introducción / ejecución, las configuraciones pequeñas pueden tener problemas. Mi servidor Ubuntu tiene 256Mo RAM y / run está configurado de forma predeterminada en 49Mo.
Al inicio, llena el sistema de archivos hasta la plenitud.
Hacer cambios en fstab no funciona para aumentar tempfs / tamaño de ejecución. Tampoco otros procedimientos que encontré en gg.
Encontré la solución para agregar en el script de inicio: /etc/rc.localla línea se mount -t tmpfs tmpfs /run -o remount,size=85M extiende al inicio. (El 85M es para mi conf.)

¡No debe codificar ninguno de estos /runcaminos!

• Uso /var/run, porque habrá un enlace simbólico para, /runsi corresponde
• /var/lock es lo mismo que arriba
• No codifique /dev/shmnunca, use siempre shm_openetc. (la API posix)