this could be in either network or here, but it has to do something with the programming of 'screen'
when ive connected to a screen on my LinuxBox thru SSH, and then the SHH connection brakes down, l8r when its up, eg after a few seconds, when i try to reconnect to the screen, eg. 'screen -dr xxx' i get a wating for about a minute maybe more.
is this my fault or is it the programming in screen?
btw... im not the only one getting this behaviour
version of screen is: Screen version 4.00.02 (FAU) 5-Dec-03
I used to use screen many years ago but haven't used it in at least 6 years. After logging back in did you check to see if your previous sshd was dead? I'm thinking screen is still attached to the still running sshd from your previous session. Also, this might be related somehow:
Screen would probably be what you want but I prefer to run a separate ssh session in each terminal and have them all displayed at the same time. I don't do anything interactive that requires me to detach a terminal which is what I used to use screen for. Now if I need to run something long I just run it in the background and redirect the output to a log. At work I use a Sunray so I can just detach the entire desktop session and reconnect at any other Sunray terminal.
Basher52 wrote:Do you have a link for that os isn't Sunray opensource? i tried to find something about it, but i only get crap when searching for it, as always :P
A Sunray (I guess it's actually Sun Ray) is a Sun thin client device that connects to a Sun server running Solaris. It's not just software so it's nothing that will help in what you want. This one looks just like the ones we have:
Might not be exactly what you are looking for - but here goes.
If you run jobs from the command line - take Voids' route by
dropping them into the background and output the results to a log file.
NB! remember to sent the stderr out as well ie. something like this
cmdtorun > somelog 2>&1
This will redirect stderr to the stdout which in this case is a file.
Using a GUI - start up a vncserver - this starts a complete gui in the
background - and using vncviewer from anywhere you can allways
log into the given vncserver desktop display#. This is an option I currently
use for GUI jobs - as I'm not sure from where and what OS is running
to connect to the machine running the Xvnc server. If no actual vncviewer
is connected, I see very little change in the execution speed, in fact
it is sometimes faster - reckon it's 'cause the job doesn't really
write to a physical device.
O yes - and when the connection gets lost - or closed - or broken....
the job on the Xvnc server continues and next time you connect
you get the screen as it is at that moment in time... the jobs are
not dependant on a connection being open