Re: [sshfs] fuse-sshfs hung diagnostics

[Daniel Y. <dy...@re...>]

At 04:16 AM 2/28/2007, Miklos Szeredi wrote:
> >...every so often, vim (gvim) hangs after connection timeout, without
> > the expected password prompt; so is the shell (hangs.)
> >
> > I would have guessed that the password dialogbox popped up and hid
> > somewhere such that I couldn't spot it, but that didn't seem to be likely.
>
>One thing you could try is run sshfs with debugging enabled:
>
>   sshfs -oreconnect,debug,sshfs_debug,loglevel=debug ... > /tmp/sshfslog 2>&1
>
>You should save the debug output after the hang, and then try to make
>it continue, and save the output again when you managed to trigger the
>password prompt.
>
>In this case it will actually ask the password in the terminal, not in
>a window.
>
>Thanks,
>Miklos


Thanks Miklos, that helped me in troubleshooting.

The mystery might be solved now. (Not 100% certain if non-debug mode is 
behaving the same way as diagnosed here. I didn't go back and repro. that 
again.)

So, whenever I execute the sshfs command line in a terminal, I put it into 
the background. (I don't remember if it put itself into the background in 
non-debug mode or if it somehow let the shell returns to its prompt.)

Because the process is in the background, it shouldn't attempt to read from 
the terminal, because if it does, terminal driver is going to send the 
*background* job a signal, SIGTTIN, which caused the background job to stop 
(if its default action wasn't modified.)

The background process can find out if it has access to the terminal (i.e. 
can read without being signaled) by checking if it is in the session 
currently having access to the terminal. (Or by checking if it is a 
foreground process somehow.) I believe tcgetsid() is the function needed. 
It return the session process group id, which can be compared with the 
process group id of the process attempting to read from the terminal.

(Please let me know if more elaboration will help.)

When ssh was trying to reconnect using password authenticate eventually, it 
sometimes caused a password dialogbox.to be shown, which didn't caused 
hang. At other times, it showed a password prompt on the terminal and 
followed, of course, by a read from the terminal. That is how it caused 
itself to be signaled and hung.

If I were to close the terminal after executing sshfs command line, the 
background process would lost the terminal and it would have no terminal to 
read from and thus not being signaled. I suppose in this case, a GUI 
password dialogbox would have been displayed somehow and everything would 
work fine.

Do you think I have described the right problem?

Thanks.


-- 
Daniel Yek