I'm just wondering if anybody out there has seen this.. I'm using screen version "Screen version 3.09.10 (FAU) 4-Sep-01" that I obtained and compiled through fink. I use it to keep some command line processes running after I close the terminal window and re-attach to them locally or sometimes remotely over SSH. Now this is going to sound strange, but it seems that once my Powermac has an uptime of about 4 days and I attempt to re-attach a screen session, I get a hard crash where I get the dimmed screen/multi-lingual "There is an error and you need to reboot your system" message. It only happens after the machine has been on a few days, never sooner than 4 days. It happens if I'm reattching locally or remotely. Wondering if anybody has experienced anything similar, or perhaps knows of a newer/different version of screen that is either precompiled or will compile on an OS X box. I'm using 10.2.6 on a DP 867 ddr powermac.
'screen' causing bigtime crashes?
- Thread starter Anthony
- Start date
Easter
Cypherpunk
that's very strange ...
did you performed the deattach when you closed the ssh session (and closed ssh nicely ... else the ssh session remain alive for about 3 days).
I always use 'screen -D -R' just to be sure to kill any ssh shell running "deattached" and restore the screen session.
Just to know, I use scren on Linux, not OS X so I could not be completely helpfull.
Good luck_
did you performed the deattach when you closed the ssh session (and closed ssh nicely ... else the ssh session remain alive for about 3 days).
I always use 'screen -D -R' just to be sure to kill any ssh shell running "deattached" and restore the screen session.
Just to know, I use scren on Linux, not OS X so I could not be completely helpfull.
Good luck_
I detach a variety of ways.. most commonly simply by closing the terminal window - I'm not sure what clicking the close button quite does, I'm sure it sends a kill signal to the shell and asks if you wish to also terminate running apps.. I've also detached with screen -d at times but this is usually if I left a screen attached and am trying to access it remotely. The actual crash happens the exact moment I press enter after issuing 'screen -r' - but like I mentioned only after the machine has been up for a few days. (I know it sounds crazy...) It doesn't really seem to have anything to do with the amount of times I detach/reattach either, because its done it the very first time I'll try to reattach if the uptime has gone far enough, other times I can detatch and reattach 50 times in a day and then the next day I'll try it just once and it crashes.
michaelsanford
Translator, Web Developer
I've been using Screen version 3.09.10 (FAU) 4-Sep-01 for a while now, and never with any problems.
I did not, however, need to Fink it. It came pre-installed in /usr/bin (Fink puts binaries in /sw/bin ) or at the very least was part of the 10.2.6 update.
Try removing (or renaming) screen in /sw/bin to something else (like screen_fink) and see if there is some kind of interaction problem between the two copies of screen. Unlikely but you never know. You can check which copy of screen it's using by typing 'which screen', since it'll search through your $PATH in the same way and report whichever the first one is it finds, which will be the one it runs.
The 'proper' way to detatch a screen is to use ^A D. ^A is screen's control escape, then D to detatch. It will then print [detatched].
I wouldn't just close the shell...that could be the source of your problems since, like Easter said, the SSH session might remain open, and you might be trying to multiplex a screen session (share the same 'screen' over more than one shell) when it doesn't want you to. That's what screen -d -r is for (it forces the screen to detatch from whatever it currently is before re-attaching it).
This also sounds kind of symptomatic of a memory leak (since the problem arises over time), but I think I would probably experience the same problem, and I don't.
What utilities are you running with screen?
I did not, however, need to Fink it. It came pre-installed in /usr/bin (Fink puts binaries in /sw/bin ) or at the very least was part of the 10.2.6 update.
Try removing (or renaming) screen in /sw/bin to something else (like screen_fink) and see if there is some kind of interaction problem between the two copies of screen. Unlikely but you never know. You can check which copy of screen it's using by typing 'which screen', since it'll search through your $PATH in the same way and report whichever the first one is it finds, which will be the one it runs.
The 'proper' way to detatch a screen is to use ^A D. ^A is screen's control escape, then D to detatch. It will then print [detatched].
I wouldn't just close the shell...that could be the source of your problems since, like Easter said, the SSH session might remain open, and you might be trying to multiplex a screen session (share the same 'screen' over more than one shell) when it doesn't want you to. That's what screen -d -r is for (it forces the screen to detatch from whatever it currently is before re-attaching it).
This also sounds kind of symptomatic of a memory leak (since the problem arises over time), but I think I would probably experience the same problem, and I don't.
What utilities are you running with screen?
michaelsanford
Translator, Web Developer
Incidentally, I find it useful to add screen listing to my log-in and log-out scripts so I can track my screens:
echo "; screen -ls ;" >> ~/.login
echo "; screen -ls ;" >> ~/.logout
The first ; is just in case there isn't a ";" or carrige-return in the line preceeding that command in those files. If you prefer, just add the blue part manually.
echo "; screen -ls ;" >> ~/.login
echo "; screen -ls ;" >> ~/.logout
The first ; is just in case there isn't a ";" or carrige-return in the line preceeding that command in those files. If you prefer, just add the blue part manually.