2

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?

  • 1
    Is it possible that you have two different copies of screen, for example one in /usr/bin and the other in /usr/local/bin, and they are not configured the same way and the session was started with one of them and you are trying to resume it with the other one? Check for differences in your $PATH and output from which screen. – Celada Jul 29 '15 at 18:38
  • That's the problem. I had a second copy of screen installed and that got put higher up in the path. I just ran /usr/bin/screen -ls and it found the session. – Alex Q Jul 29 '15 at 18:41
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.