Screen sessions getting killed but processes still live on and run
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.
Related videos on Youtube
Classified
Updated on September 18, 2022Comments
-
Classified over 1 year
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:
- I detached from the session
- performed screen -ls to check the PID
- ps -ef | grep screen
- 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. =)
-
Classified over 10 yearsThx 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.