Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is a weird situation I've run into. We have a test server off site (or off site from where I work). To access the server, I need to VPN into its network.

I ran screen to execute a long running process. After I started the process, I did the following to check screen's viability:

  1. I detached from the session
  2. performed screen -ls to check the PID
  3. ps -ef | grep screen
  4. screen -r PID

I could see there was a screen session after running these commands and re-attaching/detaching to the session.

Here's the weird part. I come back the next day and there is no screen sessions. I ran those cmds above to check but there's nothing. However, my process is still running. I didn't use nohup to run my process but for some lucky reason, my process didn't die with the session.

Does anyone know what might have happened? Why did I lose my screen session and why did I luck out and have my process keep running?

Thanks for any enlightenment. =)

share|improve this question
up vote 3 down vote accepted

You might want to grep for SCREEN instead to verify that your screen really isn't running.

Some systems have tmp cleaners that delete files in /tmp, /var/tmp, /var/run, or similar. This can result in screen not being able to find its socket files. If you can identify the PID of your session, you can do kill -CHLD <PID> to tell screen to rewrite its socket file. screen -r should then work again.

If this is what's happening, you should probably configure screen to use another directory for its sockets.

share|improve this answer
Thx for replying. 2 weeks ago when I grepped for screen, it wasn't there. However, this week, for some strange reason, my screen sessions are present when I do a screen -ls, even after waiting overnight. Go figure. I'm guessing it's what you said, that something was cleaning these screen files such that when I went to connect back, it didn't know the PID. It did say something about not finding some file at some location (didn't grab that msg from 2 wks ago). It still doesn't explain why my process luckily didn't die but that doesn't matter. Thanks. – Classified Oct 14 '13 at 19:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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