Re: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system

["L. A. Walsh" <cygwin at tlinx dot org>]

Corinna Vinschen wrote:
> I know why this happens but I don't see an easy way around that.
> Basically the problem is that Cygwin has no control over the OS mount
> points (i. e., drive letter mapping and volume ireparse points).  Given
> that, apart from C: maybe, the drive letter mapping can change any time,
> Cygwin doesn't cache the information but requests it every time it needs
> it.  This includes information required in /proc/mounts, here basically
> the FS type.  This in turn requires to open a handle to the FS, which
> may result in the observed hang.
>   
----
   Thanks for the explanation.  Looking at my ".bashrc",
I can't figure out why needed this so I can comment it out.
However, as an "aside", I'm not sure why my workaround
didn't work...though I might guess.

I tried using 'timeout' from 'coreutils-8.23-4' like:
readarray -t proc_mounts< <(timeout -k 2 1 cat /proc/mounts)

I had hoped that w/cat hanging, timeout waits 1 second (2nd
number), and if no response after the #secs after -k (2)
then it's suppose to try to kill it. 

I'm guessing that since it's a cygwin signal, it is probably
waiting for Win to return to cygwin land so cygwin can
process the signal -- but since it's off in la la land,
cygwin doesn't get a chance to clean up.

Seems like this type of thing could happen in any system
call -- i.e. for *whatever* reason, windows just decides to
spin, waiting for *something* with the result that it doesn't come
back to the cygwin layer. 

Just curious (as it likely doesn't happen that often), but how
difficult would it be to put a wrapper around any call into
windows (assuming or hoping their aren't too many different
places), and fire off a timeout as a semi-last resort to
get back control?

I'm guessing there would be too much uncertainty where it
was interrupted to continue with the user code, but maybe
along the lines of the linux kernel, the timeout could
be used to generate the equivalent of a "panic" -- that
terminates whatever was running and might possibly allow
cygwin to recover via the parent of the prog that hung?

Just an idle though -- probably more work than its worth,
but just curious too... ;-)


Thanks again for the detailed answer and I won't be annoyed
if you don't have time to answer this. ;-)

-l



> Corinna
>
>   

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple