3

I typically log into my Linux box from my Windows laptop using PuTTY and run screen there. When my corporate overlords decided to update my laptop to Windows 7 my PuTTY sessions have been freezing. I typically kill the PuTTY session and then either reattach the screen session (if it detached) or issue a "-d -r" if the screen session didn't detach when my PuTTY session froze up.

My problem is that I have a screen session that, at first, refused to detach. I'd use:

screen -d -r 6313.sessionName

but the command would just hang there.

I found that in the /var/run/screen// directory were "files" corresponding to each of my screen sessions. I noticed that the stubborn one had 700 permissions on it while the others (which were detached) had 600 permissions.

So I changed the permissions on that file to 600. Screen now lists it as "detached". However when I try to reattach to it the command, once again, just hangs there.

Using

ps aux | grep 6313

shows the process state as "Ss", which means it's in an interruptable sleep state. This is no different than any of the other detached screen sessions which show the same process status.

I'm at a loss as to how to recover this session. Any suggestions?

11
  • Probably won't help now, but when you start a screen session, how do you start it? I've always used screen -S <name> so that every session has a name I know. That way, when I want to disconnect and reconnect, I can use that name instead of a PID, such as screen -r <name> or screen -dr <name>
    – Kruug
    Jan 10, 2013 at 20:03
  • That's how I start it too. But a process ID is prefixed to the name. For example, 6313.mysession Jan 10, 2013 at 20:07
  • Do you manually prefix the pid? You should be able to access it just by referencing mysession instead of pid.mysession.
    – Kruug
    Jan 10, 2013 at 20:08
  • No, screen adds that to my session name automatically. And yes, I can reference it by using just the session name (as long as the session name is unique). I usually name my sessions after the host I'm logged into. Jan 10, 2013 at 20:12
  • Then, after using -S flag, you should be able to reference just the mysession with no need for the pid prefix.
    – Kruug
    Jan 10, 2013 at 20:14

2 Answers 2

1

When I use screencommand, I usually open the socket like this:

$ screen -S <SOCKET_NAME>

and when I want to attach or reattach I use:

$ screen -x <SOCKET_NAME>
5
  • As I explained in the first response I already do that. And screen -x is the "spy" mode. It doesn't attach to the session like using "-r" does. And I've tried that too. Same results. Jan 10, 2013 at 20:09
  • @phileasfogg -x Attach to a not detached screen. (Multi display mode). Jan 10, 2013 at 20:13
  • @phileasfogg Try this: -D -RR Do whatever is needed to get a screen session. Jan 10, 2013 at 20:17
  • "-RR" will create a new session with the same name if it's unable to detach the other session. That's not what I want. I have several jobs that need to stay running as well as several files I was editing that I don't want to lose the edits. Jan 10, 2013 at 20:19
  • @phileasfogg what is the version of the command screen? Jan 10, 2013 at 20:24
-1

To detach a screen session, you should use Ctrl+A+D. Then, to reattach the session, use screen -r <pid>. If you want to connect to a screen session that is in use, then you would use screen -dr <pid> to first detach, then reattach, the screen session.

3
  • Yes, I've already tried that as I explained above. Jan 10, 2013 at 20:07
  • You stated that you were trying to detach it with screen -d -r 6313.sessionName but that only works to detach and then reattach. That's where the confusion came in. If you wanted to just detach the screen, you wouldn't use the -r.
    – Kruug
    Jan 10, 2013 at 20:11
  • I was trying to reattach but because "screen -ls" showed it as "attached" I first had to detach it. Jan 10, 2013 at 20:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .