Any way to over-ride the "-q" option to debug a possible race condition?

[Damien Miller]

On Fri, 19 Jul 2013, Laurence Marks wrote:

> As a follow up/continuation, which I have solved how to short circuit
> the "-q", I am stuck with trying to track this issue down. Any and all
> suggestions welcome.
> 
> All I can see is (sometimes) in the output log information that the
> ssh connection was closed, nothing else. This is on Northwestern's
> (NU) supercomputer, so I don;t have access to the sshd logs. A couple
> of the NU tech support people have been looking at this, but so far
> they have nothing. They tell me that there is nothing odd in the sshd
> logs. There is nothing I can see in the Debug 1 & Debug 3 output to
> give any hints (I can send these to anyone who is interested as this
> is beyond my pay grade).

If we can't see the logs, we can't do much to help other than guess.
Sorry.

> Perhaps specific, can anyone give me conditions where ssh can turn
> into a zombie?

Zombie just means that ssh has exited and its parent process has not
yet called wait() to collect its status. ssh may have exited for any
number of reasons, so this isn't diagnostic of anything.

> Do multiple and near simultaneous access to config
> files matter?

If by "access" you mean reading (which is all that ssh ever does) then
no.

> Is there anything that can be tweaked in the code to
> provide more information about why a connection is closed? Anything
> else?

You could try to recreate the command that is being executed by whatever
is running ssh manually and see what is breaking.

-d