Impossibile creare la directory '/ var / run / screen': autorizzazione negata

26

A volte, di solito dopo un incidente o un arresto improvviso, screen rifiuta di iniziare. Comandi come

screen
screen -ls
screen -r
screen -d

risulta nel seguente output

Impossibile creare la directory '/ var / run / screen': autorizzazione negata

Qual è il problema qui? Come posso risolvere questo problema?

ubuntu unix gnu-screen

— Huey
fonte

34

Trovata una soluzione che non richiede un regolare sudo al riavvio

Da "Eric Z Ma" @ systutorials :

La directory /var/run/screen/è la directory socket per lo schermo.

Fortunatamente, lo schermo legge una variabile di ambiente SCREENDIRper ottenere una directory socket alternativa.

Quindi, per aggirare il problema, puoi creare una directory come ~/.screen:
mkdir ~/.screen && chmod 700 ~/.screen
ed esporta il SCREENDIRpuntare a quella directory:
export SCREENDIR=$HOME/.screen
Puoi anche inserire questa linea in te in ~/.bashrcmodo che abbia effetto anche in seguito.

— Krease
fonte

25

Questo problema è stato documentato qui . In breve,

/etc/rcS.d/S70screen-cleanup è in esecuzione tramite upstart molto prima di quanto si aspetti sia stato eseguito e non riesce a ripulire correttamente quella directory.

Può essere risolto con il seguente comando

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

— Huey
fonte

1

Funziona, ma devo eseguirlo ad ogni avvio, altrimenti avrò l'errore più e più volte.

— Krease

3

Mi sono imbattuto in questo mentre eseguivo una distribuzione basata su Centos / RHEL 7, e non ha nulla chiamato "pulizia schermo" in / etc.

Una soluzione alternativa che ho trovato è stata semplicemente quella di eseguire sudo screen e quindi uscire immediatamente da esso.

Dopo di che sono stato in grado di eseguire lo schermo senza alcun privilegio speciale, quindi sembra ripulire / var / eseguire in modo appropriato quando ne ho la possibilità.

— Jay Taylor
fonte

1

Posso risolvere questo problema eseguendo i seguenti comandi.

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

— Taichi Nakamura
fonte

1

Questa non è una buona soluzione. Ogni volta che riavvii devi ripetere questo.

— arupgsh,

0

TL; DR : in Debian Stretch e versioni successive, assicurati che systemd-tmpfiles-setup.servicesia stato avviato correttamente:

$:> 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
   ...

Se disabilitato ( Loaded: ... ;disabled; ...), è possibile abilitarlo con systemctl enable systemd-tmpfiles-setup.service. Se si desidera utilizzare lo schermo all'interno di un contenitore finestra mobile, è necessario avviare systemd nell'immagine del contenitore oppure eseguire systemctl start systemd-tmpfiles-setup.serviceo /etc/init.d/screen-cleanup start( come suggerito da Huey ) ogni volta dopo aver effettuato l'accesso al contenitore.

Dettagli: da Debian Stretch, lo script di avvio /etc/init.d/screen-cleanupnon viene eseguito, perché per impostazione predefinita questo servizio è mascherato ( /lib/systemd/system/screen-cleanup.service -> /dev/null), quindi systemd lo ignora.

systemd-tmpfiles-setup.serviceCrea invece /run/screenall'avvio, come configurato in /usr/lib/tmpfiles.d/screen-cleanup.conf:d /run/screen 0775 root utmp

— Jakob
fonte

Sembra che tu stia (anche) suggerendo una procedura che l'OP dovrebbe eseguire (manualmente) dopo ogni riavvio. Puoi offrire una soluzione permanente, che dovrebbe essere fatta una sola volta? Si prega di non rispondere nei commenti; modifica la tua risposta per renderla più chiara e completa.

— Scott,

@ Scott systemctl enable systemd-tmpfiles-setup.serviceche @Jacob suggerito persisteva dopo il riavvio.

— Tagar,