Por que / var / run foi migrado para / run?

Na visão geral técnica do Ubuntu 11.10 Oneiric :

Ubuntu 11.10 migrou longe /var/run, /var/locke /dev/shme agora usa /run, /run/locke /run/shmem vez disso (respectivamente).

• Codifico esses caminhos nos meus aplicativos. Por que essa alteração foi feita no Oneiric?
• O que posso fazer para tornar meus aplicativos compatíveis com versões anteriores e posteriores? Existe uma maneira melhor do que verificar primeiro a existência de /rune depois /var/run?

A intenção é reduzir o número de tmpfssistemas de arquivos. No 11.04, existem tmpfssistemas de arquivos separados em /var/lock, /var/rune /dev/shm. Se esses diretórios estivessem todos em um único diretório pai, apenas um tmpfsseria necessário. Ele também fornece um local óbvio para outros dados do estado de tempo de execução que não devem persistir durante as reinicializações.

A menos que seu aplicativo dependa de caminhos canônicos de arquivos, ele deverá ser executado sem modificação, pois os locais antigos serão vinculados aos novos. As políticas do AppArmor são um caso que depende dos nomes reais dos caminhos, motivo pelo qual foram mencionados especificamente.

Os links a seguir devem ajudar a explicar a lógica:

• 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 é um novo local tmpfs de distribuição cruzada para o armazenamento de arquivos de estado transitório - ou seja, arquivos que contêm informações em tempo de execução que podem ou não precisar ser gravadas no início do processo de inicialização e que não exigem preservação nas reinicializações.

   A /rundisponibilização do diretório nos aproxima um pouco do ponto em que é possível usar o sistema normalmente com o sistema de arquivos raiz montado somente leitura, sem a necessidade de soluções alternativas desajeitadas, como aufs/unionfssobreposições.

   /run substitui vários locais existentes descritos no padrão de hierarquia de sistemas de arquivos:

   • /var/run → /run
   • /var/lock → /run/lock
   • /dev/shm→ /run/shm[atualmente apenas o Debian planeja fazer isso]
   • /tmp→ /run/tmp[opcional; atualmente apenas o Debian planeja oferecer isso]

   • /run também substitui alguns outros locais que foram usados ​​para arquivos temporários:

   • /lib/init/rw → /run

   • /dev/.* → /run/*
   • /dev/shm/* → /run/*
   • arquivos graváveis ​​em /etc→/run/*

   (então você provavelmente pode esperar que eles também se movam).

   Fonte: objetivos de lançamento do debian

2. Eu aconselho a criar uma parte em seu software onde você define esses diretórios em variáveis, altera seu código para usá-las e depois altera as variáveis ​​com base no sistema em que é usado (mas aposto que você já sabia disso).

Pelo que li, esta foi a explicação original dada por que / run foi introduzido. http://lwn.net/Articles/436012/

Nota: desde / execute a introdução, pequenas configurações podem ter problemas. Meu servidor Ubuntu tem 256Mo de RAM e / run está definido como 49Mo.
Na inicialização, ele preenche o sistema de arquivos até a plenitude.
Fazer alterações no fstab não opera para aumentar o tamanho do tempfs / execução. Nem outros procedimentos que encontrei no gg.
Encontrei a solução para adicionar no script init: /etc/rc.locala linha mount -t tmpfs tmpfs /run -o remount,size=85M se estende na inicialização. (Os 85 milhões são para minha conf.)

Você não deve codificar nenhum desses /runcaminhos!

• Use /var/run, porque um link simbólico estará disponível para, /runse aplicável
• /var/lock é o mesmo que acima
• Não codifique /dev/shmsempre, sempre use shm_openetc (a API posix)