Sometime, usually after a crash or sudden shutdown, screen refuses to start. Commands like
screen
screen -ls
screen -r
screen -dresult in the following output
Cannot make directory '/var/run/screen': Permission denied
What's the issue here? How can I fix this?
7 Answers
Found a solution that doesn't require regular sudo on restarts
From 'Eric Z Ma' @ systutorials:
0The directory
/var/run/screen/is the socket directory for screen.Fortunately, screen reads a environment variable
SCREENDIRto get an alternative socket directory.So to work around it, you can create a directory, such as
~/.screen:mkdir ~/.screen && chmod 700 ~/.screenand export the
SCREENDIRto point to that directory:export SCREENDIR=$HOME/.screenYou can also put this line into you
~/.bashrcso that it will also take effect afterwards.
This issue has been documented here. In short,
/etc/rcS.d/S70screen-cleanupis running via upstart much earlier than it expects to have run, and is failing to correctly clean up that directory.
It can be fixed with the following command
sudo /etc/init.d/screen-cleanup startIn my case the screen-cleanup service was masked, on Debian "buster" 10.4:
$ systemctl is-enabled screen-cleanup.service
maskedAnd
$ file /lib/systemd/system/screen-cleanup.service
/lib/systemd/system/screen-cleanup.service: symbolic link to /dev/nullWhich causes the following:
$ systemctl enable screen-cleanup.service
Synchronizing state of screen-cleanup.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable screen-cleanup
Failed to enable unit: Unit file /lib/systemd/system/screen-cleanup.service is masked.The following did the trick to create the run-directory on every boot. Remove the symlink to /dev/null manually (systemctl unmask didn't work):
rm /lib/systemd/system/screen-cleanup.serviceThen enable the service:
systemctl enable screen-cleanup.serviceAnd start it:
systemctl start screen-cleanup.serviceI ran into this while running a Centos / RHEL 7 based distro, and it doesn't have anything named 'screen-cleanup' anywhere under /etc.
A workaround I found was to simply run sudo screen and then immediately exit from it.
After that I was able to run screen without any special privileges, so it appears to clean up /var/run approriately up when given the chance.
1I can fix this problem by executing the following commands.
sudo mkdir /var/run/screen
sudo chmod 777 /var/run/screenTL;DR: In Debian Stretch and later, make sure that systemd-tmpfiles-setup.service has been started successfully:
$:> 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 ...If disabled (Loaded: ... ;disabled; ...) then you might want to enable it with systemctl enable systemd-tmpfiles-setup.service. If you want to use screen within a docker container then you either have to get systemd running in your container image or you have to run systemctl start systemd-tmpfiles-setup.service or /etc/init.d/screen-cleanup start (as suggested by Huey) each time after logging into your container.
Details: Since Debian Stretch, the startup script /etc/init.d/screen-cleanup is not executed, because by default this service is masked (/lib/systemd/system/screen-cleanup.service -> /dev/null), so systemd ignores it.
Instead systemd-tmpfiles-setup.service creates /run/screen on boot, as configured in /usr/lib/tmpfiles.d/screen-cleanup.conf: d /run/screen 0775 root utmp
This can happen when the root (/) directory is not owned by root, which causes the systemd-tmpfiles-setup.service service to fail.
Run cd / && ll to see who the owner of the root directory is.
Assuming it isn't root, run sudo chown root:root / to fix it.
