{"id":342,"date":"2016-08-26T22:14:08","date_gmt":"2016-08-26T21:14:08","guid":{"rendered":"http:\/\/104.198.79.120\/?p=342"},"modified":"2016-08-26T22:19:00","modified_gmt":"2016-08-26T21:19:00","slug":"find-and-reattach-a-lost-terminal-screen-session-under-linux-mac-os-x","status":"publish","type":"post","link":"https:\/\/wp.gaborhargitai.hu\/find-and-reattach-a-lost-terminal-screen-session-under-linux-mac-os-x\/","title":{"rendered":"Find and reattach a lost terminal screen session under Linux \/ Mac OS X"},"content":{"rendered":"
Running lengthy operations (such as remote sync, video compression<\/a>) is preferred to be done in a screen<\/a> session: among other things, it enables you to do something else while your commands run in the background. For the most part you can be fairly sure that you can attach to your session anytime you want. However, there comes a time when for some reason your previously started screen session disappears. This has been reported under Mac OS X as if you leave the detached screen alone for an extended period of time, it can become terminated (or disowned by your user) automatically. In times like this the only thing that helped me are the following steps.<\/p>\n Note: I’m assuming you have brew.sh<\/a> up and running (if you don’t then by any means do it) and you have installed htop<\/a> by issuing \u00a0 If the usual screen session listing only produces an error message stating you have no lock files, like this:<\/p>\n Then by all means follow along as we try to make it recreate the missing socket!<\/p>\n First, dive in and find the actual screen process among the currently running processes. Open up a Terminal and run this:<\/p>\n if you are not getting any output then try with capital letters like this:<\/p>\n You should see something like this:<\/p>\n username\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 3217 \u00a0 0.0\u00a0 0.0\u00a0 2460736\u00a0 \u00a0 368 \u00a0 ??\u00a0 Ss \u00a0 Wed09PM \u00a0 0:10.10 SCREEN -t conv<\/p><\/blockquote>\n the second column (here it’s “3217”) is the important process ID (or pid for short) we’ll be looking for. If you have multiple screen sessions then be sure to note the pid of the one that you currently have no access to (hence lost).<\/p>\n Now, we need to fire up\u00a0htop<\/strong> by running this:<\/p>\n You’ll be presented with a summary of resources along with a lengthy list of running processes. On your keyboard hit Fn + F3<\/strong> (if you have multimedia keys enabled – if not, just press F3) to activate Search mode and start typing “screen”. The cursor should jump to the first screen session – make sure you select one that has the same\u00a0pid<\/strong> as the one from before.<\/p>\n Finally, we are going to force the screen session to recreate the socket by sending itt a SIGCHLD signal. While your desired screen session with the right pid is selected, press Fn + F9<\/strong> (or just F9) to bring up the Kill Menu within htop. Here go down to number 20 which says\u00a0SIGCHLD<\/strong> and hit Enter to Send the process that signal.<\/p>\n This should force it to recreate the fifo socket so if you run the command to reattach ( Alternatively, if you do not want to use htop then a simple kill command does the very same – for the sake of completeness, here it is using the pid<\/strong> from above:<\/p>\nbrew install htop<\/code>\u00a0 in your Terminal.app – I agree that there are more sophisticated ways of sending KILL signals to processes but having htop around is nice.<\/p>\n
$ screen -list\r\nNo Sockets found in \/var\/run\/screen\/S-username<\/code><\/pre>\n
ps aux |grep screen<\/code><\/p>\n
ps aux |grep SCREEN<\/code><\/p>\n
htop<\/code><\/p>\n
screen -r <pid><\/code> ) then it should now bring up your lost screen session without a single error.<\/p>\n