From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 Description of problem: If to ssh to another machine, "work" there some time and return by 'exit' will at most cases result with dead console. Version-Release number of selected component (if applicable): How reproducible: Sometimes Steps to Reproduce: 1.Go with ssh to different machine; 2.Work there for some time; 3.Type 'exit' to leave this ssh session; Actual Results: Console will at most cases become empty but no prompt will appear and no keyboard input will make any difference (ctrl+c and such): http://www.vendomar.ee/~ivo/ssh_exit.png http://www.vendomar.ee/~ivo/ssh_exit_ps.png Expected Results: Previous console prompt. Additional info: There is no differences between console and X - chances to get dead console is very high.
Actually, it waits for some timeout. If you will leave console in such state for some time (few minutes), the prompt will come back, and you will get "expected results". :) Sometimes it could be really annoying though.
OK, I have to try it, but is it still a bug or is it intentional? Somehow I think it is a bug.
So I am waiting for this timeout - 4 hours already...
I found the cause of the problem: if user started a background program during ssh session, ssh is not capable to exit until this background program has been terminated. Test A: 1) ssh to a host; 2) run: sleep 10 >/dev/null & exit Results: It takes 10 seconds to regain working console. Test B: 1) ssh to a host; 2) run: sleep 100 >/dev/null & exit Results: It takes 100 seconds to regain working console. Note: If program happens to not exit itself then there will be permanently dead console.
'>/dev/null' is overkill as 'sleep' will not print out anything...
I changed it over to bash as I suspect it to be source of this problem.
Why do you think that? Seems like an ssh problem to me.
You can also cause this to happen by logging into a RedHat server, restart cron with something like this: service crond restart then logout. Your shell is now forever locked.
Perhaps this problem should be renamed "background tasks hang ssh". It is very annoying but after a while you get trained to remember to stop background tasks before exiting. I got caught again a few minutes ago, which is why I'm here now. However, what if you want to start a background task and exit? It still should be fixed (or defended?) but I think severity should be normal or low.
Just to remind - the issue is still here even with FC2.
It's not only background tasks - I can replicate this problem precisely every time if I wish. In the cases that I have seen it relates to receiving certain output onto the ssh console while working. If I then try to exit it will hang. Either ssh receives a bad character that it "doesn't like" or it receives something to stdout/stderr that it doesn't like - perhaps a program leaving one of these open? Either way, it isn't just background tasks :(
This is a known issue in the openssh faq: http://www.openssh.org/faq.html#3.10 http://bugzilla.mindrot.org/show_bug.cgi?id=52 basically, ssh can't close its FDs if a subprocess still has STDOUT/ERR open.
*** This bug has been marked as a duplicate of 39128 ***