> On Apr 15, 05 11:46:00 +0200, Joakim Ahl�n wrote: > > > > * Run screen -d -r, which hangs. Leave it hanging. > > > > * Start up another SSH session, and su to root > > > > * Find the PID of the SCREEN-process (with capitals), and > > > run "strace > > > > -p [pid of SCREEN] 2>/dev/null" > > > > > > what would strace print when not redirecting to /dev/null? > > > I could imagine it hangs in a write() or read(), right? > > > > > > > No, the strace doesn't hang. Directly when starting strace, > the hanged > > "screen -d -r" gets unlocked and works fine. This makes > strace print > > what usually is printed if you strace a normal > screen-process. Lots of > > system calls. > > Okay. So I am perhaps on the wrong track. > Please show us how the strace output starts, when it happens again.
I'll try that. You can probably reproduce the error yourself by reseting your (not the servers) network connection in a way which doesn't send an ICMP reset to the server. Just yanking out your cable probably might work depending on your local switch. Removing the plug to the phone line if you're using ADSL will most likely induce this error. For the record, i am using a windows machine with putty as ssh client. My ssh server is linux redhat with openssh 3.4p1. I'm not sure if the behaviour could be different with other clients/servers. I cannot test this myself right now, but if the problem appears by itself i'll send you the strace log. Regards Joakim _______________________________________________ screen-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/screen-users
