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. =)

2 Answers

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.

1

This happened to me and my co-worker again recently and he proposed this as a possible reason why this happened. He thinks due to the company timing out our connection, it kills screen.

We had several screen sessions running, each with its own long running job (for simplicity, we'll call it session A and B). The job on session A finished early and that session returned to the prompt. When the timeout period elapsed due to inactivity, it logged us out of session A. Session B is still running its job when this happened but we think when the parent process dies (in this case screen), it takes with it all sessions.

The process that was running on Session B is now inherited by screen's parent, which is the init process or process 1 and thus keeps running when we checked the next morning.

This hypothesis was sort of backed up by running an experiment. This was run on Centos. We started screen and opened two sessions. One session we periodically ran a cmd to keep it alive. The other we ignored. After like 10 min, screen was terminated and with it, both sessions that we opened up.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

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