Почему / var / run был перенесен в / run?

Из технического обзора Ubuntu 11.10 Oneiric :

Ubuntu 11.10 мигрировал от /var/run, /var/lockи /dev/shmи теперь использует /run, /run/lockи /run/shmвместо этого (соответственно).

• Я жестко кодирую эти пути в своих приложениях, почему это изменение сделано в Oneiric?
• Что я могу сделать, чтобы сделать мои приложения обратно и вперед совместимыми? Есть ли лучший способ, кроме проверки сначала на наличие /run, а потом /var/run?

Цель состоит в том, чтобы уменьшить количество tmpfsфайловых систем. На 11.04 есть отдельные tmpfsфайловые системы на /var/lock, /var/runи /dev/shm. Если бы все эти каталоги находились в одном родительском каталоге, тогда был tmpfsбы нужен только один каталог . Это также обеспечивает очевидное местоположение для дальнейших данных о состоянии во время выполнения, которые не должны сохраняться при перезагрузках.

Если ваше приложение не зависит от канонических путей к файлам, ваше приложение должно работать без изменений, так как старые местоположения будут связаны с новыми. Политики AppArmor - это один случай, который зависит от реальных имен путей, именно поэтому он был упомянут конкретно.

Следующие ссылки должны помочь объяснить обоснование:

• 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 это новое расположение tmpfs для перекрестного распространения для хранения файлов переходного состояния, то есть файлов, содержащих информацию времени выполнения, которые могут или не должны быть записаны в начале процесса загрузки и которые не требуют сохранения при перезагрузках.

   Предоставление /runдоступа к каталогу приближает нас к тому моменту, когда можно нормально использовать систему с монтированной корневой файловой системой только для чтения, не требуя каких-либо неуклюжих обходных путей, таких как aufs/unionfsналожения.

   /run заменяет несколько существующих местоположений, описанных в стандарте иерархии файловой системы:

   • /var/run → /run
   • /var/lock → /run/lock
   • /dev/shm→ /run/shm[в настоящее время только Debian планирует сделать это]
   • /tmp→ /run/tmp[необязательно; в настоящее время только Debian планирует предложить это]

   • /run также заменяет некоторые другие местоположения, которые использовались для временных файлов:

   • /lib/init/rw → /run

   • /dev/.* → /run/*
   • /dev/shm/* → /run/*
   • записываемые файлы под /etc→/run/*

   (так что вы, вероятно, можете ожидать, что они тоже будут двигаться).

   Источник: цели выпуска Debian

2. Я бы посоветовал создать часть в вашем программном обеспечении, где вы устанавливаете эти каталоги в переменные, изменяете свой код для использования этих переменных, а затем изменяете переменные в зависимости от системы, в которой они используются (но я уверен, что вы уже знали об этом).

Из того, что я прочитал, это было оригинальное объяснение того, почему / run был введен. http://lwn.net/Articles/436012/

Примечание: после введения / запуска небольшие конфигурации могут вызвать проблемы. Мой сервер Ubuntu имеет 256Mo RAM и / run по умолчанию установлен на 49Mo.
При запуске он заполняет файловую систему до полноты.
Внесение изменений в fstab не способствует увеличению темпов / размера запуска. Также как и другие процедуры, которые я нашел на GG.
Я нашел решение добавить в сценарий инициализации: /etc/rc.localстрока mount -t tmpfs tmpfs /run -o remount,size=85M при расширении при запуске. (85M для моей конф.)

Вы не должны жестко кодировать ни один из этих /runпутей!

• Используйте /var/run, потому что символическая ссылка будет на месте, /runесли применимо
• /var/lock такой же, как указано выше
• Никогда не /dev/shmиспользуйте shm_openжесткий код , всегда используйте и т. Д. (API posix)