Nie można utworzyć katalogu „/ var / run / screen”: Odmowa dostępu

26

Czasami, zwykle po awarii lub nagłym wyłączeniu, screenodmawia uruchomienia. Polecenia takie jak

screen
screen -ls
screen -r
screen -d

wynik w następujący wynik

Nie można utworzyć katalogu „/ var / run / screen”: Odmowa dostępu

O co tu chodzi? Jak mogę to naprawić?

ubuntu unix gnu-screen

— Huey
źródło

36

Znaleziono rozwiązanie, które nie wymaga regularnego sudo przy ponownym uruchomieniu

Z „Eric Z Ma” @ systutorials :

Katalog /var/run/screen/jest katalogiem gniazd dla screena.

Na szczęście screen odczytuje zmienną środowiskową, SCREENDIRaby uzyskać alternatywny katalog gniazd.

Aby obejść ten problem, możesz utworzyć katalog, taki jak ~/.screen:
mkdir ~/.screen && chmod 700 ~/.screen
i wyeksportuj SCREENDIRdo punktu do tego katalogu:
export SCREENDIR=$HOME/.screen
Możesz również umieścić tę linię w tobie, ~/.bashrcaby działała ona później.

— Krease
źródło

25

Ten problem został udokumentowany tutaj . W skrócie,

/etc/rcS.d/S70screen-cleanup działa przez upstart znacznie wcześniej, niż się spodziewa, i nie może poprawnie wyczyścić tego katalogu.

Można to naprawić za pomocą następującego polecenia

sudo /etc/init.d/screen-cleanup start

— Huey
źródło

1

To działa, ale muszę go uruchamiać przy każdym uruchomieniu, w przeciwnym razie błąd będzie się powtarzał.

— Krease

3

Natknąłem się na to podczas uruchamiania dystrybucji opartej na Centos / RHEL 7 i nigdzie w / etc nie ma nic takiego jak „czyszczenie ekranu”.

Obejściem, które znalazłem, było po prostu uruchomienie, sudo screena następnie natychmiastowe wyjście z niego.

Potem mogłem uruchomić ekran bez żadnych specjalnych uprawnień, więc wygląda na to, że wyczyszczę / var / uruchomię natychmiast, gdy tylko nadarzy się okazja.

— Jay Taylor
źródło

1

Mogę rozwiązać ten problem, wykonując następujące polecenia.

sudo mkdir /var/run/screen
sudo chmod 777 /var/run/screen

— Taichi Nakamura
źródło

1

To nie jest dobre rozwiązanie. Za każdym razem, gdy uruchomisz ponownie, musisz to zrobić ponownie.

— arupgsh

0

TL; DR : W Debian Stretch i późniejszych upewnij się, że systemd-tmpfiles-setup.servicezostał pomyślnie uruchomiony:

$:> systemctl status systemd-tmpfiles-setup.service
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories
   Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled)
   Active: active (exited) since Thu 2018-06-21 19:54:06 CEST; 41min ago
   ...

Jeśli wyłączone ( Loaded: ... ;disabled; ...), możesz chcieć włączyć za pomocą systemctl enable systemd-tmpfiles-setup.service. Jeśli chcesz korzystać z ekranu w pojemniku Döcker wtedy trzeba albo dostać Systemd działa w pojemniku obrazu lub trzeba uruchomić systemctl start systemd-tmpfiles-setup.servicelub /etc/init.d/screen-cleanup start( jak sugeruje Huey ) za każdym razem po zalogowaniu do swojego pojemnika.

Szczegóły: Od czasu Debian Stretch skrypt startowy /etc/init.d/screen-cleanupnie jest wykonywany, ponieważ domyślnie ta usługa jest maskowana ( /lib/systemd/system/screen-cleanup.service -> /dev/null), więc systemd ją ignoruje.

Zamiast tego systemd-tmpfiles-setup.servicetworzy /run/screenprzy rozruchu, jak skonfigurowano w /usr/lib/tmpfiles.d/screen-cleanup.conf:d /run/screen 0775 root utmp

— Jakob
źródło

Wygląda na to, że sugerujesz procedurę, którą OP musiałby wykonać (ręcznie) po każdym ponownym uruchomieniu. Czy możesz zaoferować trwałe rozwiązanie, które musiałoby zostać wykonane tylko raz? Proszę nie odpowiadać w komentarzach; edytuj swoją odpowiedź, aby była jaśniejsza i bardziej kompletna.

— Scott

@Scott systemctl enable systemd-tmpfiles-setup.servicesugerowane przez @Jacob utrzymywało się po ponownym uruchomieniu komputera.

— Tagar