https://bugzilla.mindrot.org/show_bug.cgi?id=2619
Darren Tucker <dtuc...@zip.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #2879|0 |1 is obsolete| | --- Comment #8 from Darren Tucker <dtuc...@zip.com.au> --- Created attachment 2881 --> https://bugzilla.mindrot.org/attachment.cgi?id=2881&action=edit Do not attempt to re-send SIGTTOU if we got it while restoring terminal modes. Todd Miller of OpenBSD came up with the following analysis: """ It's not really useful to generate SIGTTOU when restoring terminal the mode in readpassphrase(). If we get SIGTTOU it means the process is not in the foreground process group which, in most cases, means that the shell has taken possession of the tty. Basically what happens is this: 1) sftp forks ssh 2) user suspends sftp (really ssh) at the password prompt 3) sftp receives SIGTSTP and suspends 4) shell takes the controlling terminal 5) ssh receives SIGTSTP, tries to restore terminal mode, receives SIGTTOU 6) ssh sends itself SIGTSTP and suspends 7) user resumes sftp (and the ssh child) 8) ssh sends itself SIGTTOU and suspends 9) sftp appears to be hung (though you can bg and fg it to get back) sftp should probably install signal handlers for SIGTSTP, SIGTTOU and SIGTTIN and wait for its child to suspend like scp does but I'll save that for another diff. """ and the attached patch, which also seems to work for me. -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs