Dokument ten wyjaśnia czym jest katalog /run i do czego służy. Jest to luźne tłumaczenie tego tekstu.
Katalog ten jest zakładany przez menedżera systemu i usług systemd (począwszy od wersji 26). Wcześniej programy uruchamiane podczas wczesnego startu systemu umieszczały swoje dane wykonawcze w rozmaitych ukrytych podkatalogach katalogu /dev. Pierwszym z nich był /dev/.udev. Z czasem doszły następne: /dev/.mdadm, /dev/.systemd, /dev/.mount, dracut, initscripts, tools. W zależności od rodzaju dystrybucji mogło być ich więcej. Przyczyną zakładania tych katalogów był fakt, że katalog /dev był typu tmpfs (umieszczony w pamięci operacyjnej) oraz był dostępny już we wczesnej fazie rozruchu systemu. Katalog /var/run z drugiej strony stawał się dostępny dopiero w późnej fazie rozruchu, jako że /var mógł znajdować się na odrębnym systemie plików.
Jednakże /dev od zawsze był nieodpowiednim i nieładnym miejscem na dane wykonawcze: dane te nie są żadnym plikiem urządzenia i dlatego nie powinny znajdować się w nim. Również ukrywanie powyższych katalogów przed administratorem (poprzez umieszczenie kropki na początku) nie jest dobrym pomysłem. Ponadto umieszczanie części danych wykonawczych w /var/run/xxx a innych w /dev/.yyy może wprowadzać użytkownika w błąd. Argumentem przeciw był także fakt, że podczas rozruchu były wykorzystywane narzędzia zaprojektowane do pracy po uruchomieniu systemu. I to wymuszało wiele skomplikowanych przesunięć pomiędzy tymi dwoma systemami plików.
Wiele dystrybucji poszukiwało własnych rozwiązań powyższych niedogodności stosując nierzadko inne brzydkie obejścia tego problemu. W Debianie był np. /lib/init/rw - system plików tmpfs fs montowany we wczesnej fazie botowania. W Ubuntu zaś montowano katalog /var/run jako tmpfs jeszcze wcześniej niż zamontowano /run. Większość dystrybucji jednak nie przejmowała się niedogodnościami i po prostu używała rozwiązania /dev/.xxx.
W końcu zebrali się przedstawiciele Debiana, Suse, Ubuntu, Fedory i innych dystrybucji i przedyskutowali zalety i wady używanych rozwiązań. Zaproponowano wiele rozmaitych obejść problemu i ostatecznie zdecydowano, że katalog /var/run nie powinien należeć do /var tylko powinien być odrębnym systemem plików tmpfs zamontowanym w katalogu głównym. Ponadto zdecydowano, że podkatalog /var/lock zostanie przeniesiony do /run/lock a w celu zachowania kompatybilności /var/{run,lock} będą symlinkami do /run/{.,lock}
Podsumowując, poniżej znajdują się korzyści wypracowanego rozwiązania: