Dlaczego migrowano / var / run do / run?

Z technicznego przeglądu Ubuntu 11.10 Oneiric :

Ubuntu 11.10 ma przeniesione z dala od /var/run, /var/locki /dev/shmteraz używa /run, /run/locka /run/shmzamiast (odpowiednio).

• Na stałe zapisuję te ścieżki w swoich aplikacjach, dlaczego wprowadzono tę zmianę w Oneiric?
• Co mogę zrobić, aby moje aplikacje były kompatybilne wstecz i dalej? Czy istnieje lepszy sposób niż sprawdzenie najpierw istnienia /run, a następnie /var/run?

Ma to na celu zmniejszenie liczby tmpfssystemów plików. Na 11.04, istnieją oddzielne tmpfssystemy plików w /var/lock, /var/runi /dev/shm. Gdyby wszystkie te katalogi znajdowały się w jednym katalogu nadrzędnym, tmpfspotrzebny byłby tylko jeden katalog . Zapewnia również oczywistą lokalizację dla dalszych danych stanu środowiska wykonawczego, które nie powinny się utrzymywać po ponownym uruchomieniu.

O ile aplikacja nie zależy od kanonicznych ścieżek plików, aplikacja powinna działać bez modyfikacji, ponieważ stare lokalizacje będą dowiązane symbolicznie do nowych. Zasady AppArmor to jeden przypadek, który zależy od rzeczywistych nazw ścieżek, dlatego właśnie został wspomniany.

Poniższe linki powinny pomóc wyjaśnić uzasadnienie:

• 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 jest nową lokalizacją tmpfs z dystrybucją krzyżową do przechowywania plików stanu przejściowego - to znaczy plików zawierających informacje w czasie wykonywania, które mogą, ale nie muszą, zostać zapisane na wczesnym etapie procesu rozruchu i które nie wymagają zachowania podczas ponownego uruchamiania.

   Udostępnienie /runkatalogu przybliża nas do punktu, w którym możliwe jest normalne korzystanie z systemu z głównym systemem plików zamontowanym tylko do odczytu, bez konieczności stosowania niepotrzebnych obejść, takich jak aufs/unionfsnakładki.

   /run zastępuje kilka istniejących lokalizacji opisanych w Standardie hierarchii systemów plików:

   • /var/run → /run
   • /var/lock → /run/lock
   • /dev/shm→ /run/shm[obecnie tylko Debian planuje to zrobić]
   • /tmp→ /run/tmp[opcjonalnie; obecnie tylko Debian planuje to zaoferować]

   • /run zastępuje również niektóre inne lokalizacje, które były używane dla plików przejściowych:

   • /lib/init/rw → /run

   • /dev/.* → /run/*
   • /dev/shm/* → /run/*
   • zapisywalne pliki w /etc→/run/*

   (więc prawdopodobnie można się spodziewać, że będą się również poruszać).

   Źródło: cele wydania Debiana

2. Poradziłbym utworzenie części w twoim oprogramowaniu, w której ustawiasz te katalogi w zmiennych, zmieniasz kod, aby używać tych zmiennych, a następnie zmieniasz zmienne w oparciu o system, w którym jest używany (ale założę się, że już o tym wiedziałeś).

Z tego, co przeczytałem, było to oryginalne wyjaśnienie, dlaczego wprowadzono / run. http://lwn.net/Articles/436012/

Uwaga: od wprowadzenia / uruchomienia małe konfiguracje mogą powodować problemy. Mój serwer Ubuntu ma 256 MB pamięci RAM i / run jest domyślnie ustawiony na 49 milionów.
Podczas uruchamiania wypełnia system plików aż do zapełnienia.
Wprowadzanie zmian w fstab nie działa, aby zwiększyć tempfs / run run. Podobnie jak inne procedury, które znalazłem na gg.
Znalazłem rozwiązanie do dodania w skrypcie inicjującym: /etc/rc.locallinia, mount -t tmpfs tmpfs /run -o remount,size=85M która rozszerza się przy starcie. (85M jest dla mojej konf.)

Nie powinieneś kodować żadnej z tych /runścieżek!

• Użyj /var/run, ponieważ w /runrazie potrzeby będzie dostępne dowiązanie symboliczne
• /var/lock jest taki sam jak powyżej
• Nigdy nie koduj na stałe /dev/shm, zawsze używaj shm_openetc (posix API)