No screen to be resumed

A

andyzammy

Hi all,

First time this has happened to me. I detached a session last night with about 5 windows inside it, and today I type in % screen -r
and the result is:
Code: 
There is no screen to be resumed.
Which is strange because there were definitely 3 detached screens before I went to bed. I think they're still there too:
% ps -auxww | grep screen
Code: 
root   6057  0.0  0.1  3708  1968  ??  Ss   Thu03PM   0:26.08 screen
root   8286  0.0  0.0  3708  1532  ??  Is   17Apr12   0:01.06 screen
root  36206  0.0  0.1  3708  1700  ??  Is   24Apr12   0:00.04 screen
rofl  25480  0.0  0.0  3500  1040   0  R+    1:38PM   0:00.00 grep screen

Does anybody know how I can salvage the sessions? They contain processes that are still running. I guess killing off the screens will kill them off.. if I'm even able to:

% screen -r 6057
Code: 
There is no screen to be resumed matching 6057.

Strange one!

Edit: I noticed that they appear to be processes owned by root if I'm reading ps correctly, but I definitely created them as myself. I tried to reattach as root anyway and got the same results.
 
It appears that these screen sessions were started as "root", whereas you're operating as "rofl". su to root and try again.
 
DutchDaemon said:
It appears that these screen sessions were started as "root", whereas you're operating as "rofl". su to root and try again.
Click to expand...

I can say with 100% certainty that the two older screens were created by me (rofl). 95% sure the last one (with 5 windows) was created by me too. However as they do indeed appear to be owned by root I did try, and got exactly the same message.

SirDice said:
What does [cmd=]screen -ls[/cmd] tell you?
Click to expand...

As me:
Code: 
No Sockets found in /tmp/screens/S-rofl.

As root:
Code: 
No Sockets found in /tmp/screens/S-root.
 
All detached screen sessions run as root.

Any other sockets in /tmp/screens/?
 
SirDice said:
All detached screen sessions run as root.

Any other sockets in /tmp/screens/?
Click to expand...

No, but something has just clicked. I recently did a rm inside /tmp. I didn't think I had set the recursive flag, but I must have since nothing else is there. I didn't realize /tmp was needed for screen.

Is there any way to recover the sessions without these sockets? Maybe rebuild them, or reattach the processes to different sockets? I'll browse the man pages when I can, there's a LOT more to this prog than I originally thought.
 
SirDice said:
All detached screen sessions run as root.
Click to expand...

They do? One more reason to like tmux.

Code: 
ddaemon   10049   0.0  0.0  16512   2516  ??  Ss   12:54PM   0:00.01 tmux: server (/tmp/tmux-1001/default) (tmux)
 
DutchDaemon said:
They do? One more reason to like tmux.
Click to expand...

I skimmed screen() and couldn't find a way to recover a screen without a socket file. tmux() describes exactly how to recover from my current problem so I think I will give it a try. I think that the Ctrl-B binding is going to annoy me when it gets in the way of vi though.
 
andyzammy said:
I think that the Ctrl-B binding is going to annoy me when it gets in the way of vi though.
Click to expand...
You can change it to Ctrl-A if you want. Should be explained in the man page too.
 
SirDice said:
You can change it to Ctrl-A if you want. Should be explained in the man page too.
Click to expand...

Yeah that will probably get done. I want to try with default though. I don't know why but I always try to work with out of the box configs. It would make for a more universal experience if I were to ever use the software elsewhere, but admittedly I don't have that problem at the moment :D
 
Heh, I configure .screenrc on all my servers to use CTRL+B instead of CTRL+A, simply because CTRL+A means "go to start of line" and not "hey, I want to issue a command". :) Whoever thought CTRL+A would be good for screen commands was crazy. :)
 
phoenix said:
Heh, I configure .screenrc on all my servers to use CTRL+B instead of CTRL+A, simply because CTRL+A means "go to start of line" and not "hey, I want to issue a command". :) Whoever thought CTRL+A would be good for screen commands was crazy. :)
Click to expand...

That's strange, I was just thinking that whoever thought CTRL+B would be good for tmux commands was crazy. He must be one of 'your lot' :D

I was also wondering why ALT isn't implemented in either of the terminal multiplexers? It's a more comfortable key to reach, most/all programs/shells seem to need a certain CTRL+key combination. Why not make a control interface that is less prone to interfere with other programs? Is that also down to EMACS?

inky said:
Hello, maybe just server was rebooted - so screen is no more attachable.
Click to expand...

Hi, screen was definitely still there but the problem was that I deleted everything inside /tmp, some of which it needed to run. Thanks for the tip though :)
 
And ALT tends to be picked up by GUI programs to access menus, so using it in a GUI terminal emulator (like Konsole) would be a pain.
 
kpa said:
The alt key is a PC invention, terminals like the VT100 (http://en.wikipedia.org/wiki/VT100) didn't have it in their keyboards.
Click to expand...

Is there some sort of standard that requires backwards compatibility with ancient tech? :D

phoenix said:
And ALT tends to be picked up by GUI programs to access menus, so using it in a GUI terminal emulator (like Konsole) would be a pain.
Click to expand...

Didn't think about GUIs! I've not really got into heavy customisation yet, just a few aliases in .cshrc that abbreviate long regular commands. It's going to be a fun ride writing some up, breaking my install, realizing I forgot to back them up, and having to remember/rewrite what I had!
 
You must log in or register to reply here.
Back
Top