running screen in a shell can't find sessions but running screen during ssh login can

Question

I am using the RemoteLoginAutoScreen script to start a screen session when I ssh into a host.

Differences from linked script: I am using zsh and the RemoteLoginAutoScreen uses bash

The problem that I'm running into is that my ssh connect was disconnected (which happens frequently and hence the auto-screen configuration) and I'm having trouble reconnecting to my existing screen session.

On the host I can see that my screen process is still running and the screen sockets still exist:

$ ps auxww | grep -i screen | grep alexq
alexq     1818  0.0  0.0 103452   868 pts/19   S+   18:08   0:00 grep --color=auto -i screen
alexq    20270  0.0  0.0 120040  2004 ?        Ss   Jul21   0:19 SCREEN -R

$ ls -al /var/run/screen/S-alexq
total 6
drwx------ 2 alexq    alexq  4096 Jul 29 17:26 .
drwxrwxr-x 5 root     screen 4096 Jul 21 21:33 ..
prwx------ 1 alexq    alexq     0 Jul 29 17:46 20270.pts-14.myhost

But when I'm logged in (without being in a screen session) screen can't find my existing session:

$ screen -ls
No Sockets found in /tmp/uscreens/S-alexq.

Based on this question I've tried setting the SCREENDIR environment variable to /var/run/screen/S-alexq But when I do that screen still can't find the sessions:

$ export SCREENDIR=/var/run/screen/S-alexq
$ screen -ls
No Sockets found in /var/run/screen/S-alexq.

$ export SCREENDIR=/var/run/screen
$ screen -ls
You are not the owner of /var/run/screen.

What I'm really confused about is that when I replace starting screen with "screen -ls" in my ~/.zshrc file I get the following printed to the console:

There are screens on:
    20270.pts-14.myhost   (Attached)
1 Sockets in /var/run/screen/S-alexq.

So for some reason screen during my ssh login can find the existing session but when I'm on the console screen can't find the session.

Can anyone help me to figure out why screen can only see the sessions during my ssh login and not afterwards?

Answer 1

You have two copies of screen. One of them stores its sessions in /tmp/uscreens and the other stores its sessions in /var/run/screen, so they don't see each other's sessions.

Even if you could force them to see each other's sessions there's a chance that the copies of screen are different versions and bad things would happen if the two talked to one another. However in any case you've already observed that it doesn't allow you to force it to use a different session directory using $SCREENDIR and that's a security measure (because screen is privileged, probably setuid or setgid, depends on the exact OS and configuration).

The problem happens because you have a different $PATH depending on how exactly you log in.

The solution is to use the same copy of screen to resume a session as was used to start it. Or you can disable or uninstall one of the copies of screen to remove the possibility of future confusion.