On Thu, 22 Sep 2005, Frank Cusack wrote:
This is a known problem, for openssh at least. You shouldn't send EOF and CLOSE (are these actual protocol messages?) on command termination, you should only send it on EOF from the read fd connected to the command's stdout.
On September 22, 2005 8:47:55 PM -0400 der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:- User authentication succeeds. - Client opens a "session" channel (call it A). - Server confirms the open. - Client requests agent and X11 forwarding on A. - Server accepts forwardings. - Client sends an "exec" request on A. The requested command is an X terminal emulator. - Terminal emulator starts (opening an X connection) and backgrounds itself (which looks like dying, to the server). - Server notices command death and sends EOF and CLOSE on A. - Client sends CLOSE on A, acking the server's CLOSE. - Server tears down forwardings for A, 'cause the channel's closed. - Something running under the terminal emulator does something which wants agent access, or which wants a new X connection, but the forwarding is now gone! Obviously, something here needs to change. But what? Everything leading up to the problem looks reasonable, but it sure adds up to "broken" in practice. The most dubious point I see is the terminal emulator backgrounding itself - but that worked fine with the old ssh1 implementation, and it doesn't seem totally unreasonable to expect it to work still.
The problem with that is you end up with "hung" sessions if you start a background process that doesn't close it's stdout (e.g. attempting to run a process as a daemon that really is meant to run in the foreground). So a compromise is that you note process death but wait until your select() or poll() loop indicates that there is no data ready. For some reason, openssh on BSD and openssh on Linux act differently here, due to kernel differences. It's been so long that I don't remember the details. Now, if you implemented the compromise method, this wouldn't solve your problem, because an idle xterm isn't going to have data ready. But that's all a red herring, because really you should notice that the forwarded session is still open and delay closing the session until the forwarding has gone bye-bye. At least, that's what openssh does. Even if I'm off track here, I suggest sending a note to the openssh list. It sounds off topic for this list. -frank