Darren Tucker <> changed:

           What    |Removed                     |Added
   Attachment #2879|0                           |1
        is obsolete|                            |

--- Comment #8 from Darren Tucker <> ---
Created attachment 2881
Do not attempt to re-send SIGTTOU if we got it while restoring terminal

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
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

Reply via email to