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

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

[L A Walsh]

I noticed my local terminals were not opening w/a shell prompt, but
would timeout if I waited long enough...(1-2 minutes? maybe?).

Turns out, one of my mounted net-drives was a down-system, so
if I was trying to access the drive (or content on it), I can see
it hanging.

But what about "cat /proc/mounts" which is dumping out text
like:

Z: /z ntfs binary,user,noumount,auto 1 1

should require accessing and hanging for a few minutes?
Is it determining the network file type?  Wouldn't that
remain constant for a given session (like I doubt that
ntfs would exchange with smbfs and go back on fixed IP
machines).

I've tried using 'timeout', but it doesn't seem to work:

read -t proc_mounts < <(timeout -k 2 1 cat /proc/mounts)

(still hangs)

tnx,
-l






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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

On Jan 10 20:43, L A Walsh wrote:
> I noticed my local terminals were not opening w/a shell prompt, but
> would timeout if I waited long enough...(1-2 minutes? maybe?).
> 
> Turns out, one of my mounted net-drives was a down-system, so
> if I was trying to access the drive (or content on it), I can see
> it hanging.
> 
> But what about "cat /proc/mounts" which is dumping out text
> like:
> 
> Z: /z ntfs binary,user,noumount,auto 1 1
> 
> should require accessing and hanging for a few minutes?
> Is it determining the network file type?  Wouldn't that
> remain constant for a given session (like I doubt that
> ntfs would exchange with smbfs and go back on fixed IP
> machines).
> 
> I've tried using 'timeout', but it doesn't seem to work:
> 
> read -t proc_mounts < <(timeout -k 2 1 cat /proc/mounts)
> 
> (still hangs)

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.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[L. A. Walsh]

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Jan 11 19:13, L. A. Walsh wrote:
> 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.

Exactly.  The hanging call is just some NtOpenFile call on the
filesystem.  The timeout is an unfortunate effect of accessing
a remote drive.  One problem here is that Cygwin doesn't support
interrupting of synchroneous Windows I/O calls from the signal
handler.  That's something I'm planning to do at one point, but
don't hold your breath.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[cyg Simple]

On 1/12/2017 10:00 AM, Corinna Vinschen wrote:
> On Jan 11 19:13, L. A. Walsh wrote:
>> 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.
> 
> Exactly.  The hanging call is just some NtOpenFile call on the
> filesystem.  The timeout is an unfortunate effect of accessing
> a remote drive.  One problem here is that Cygwin doesn't support
> interrupting of synchroneous Windows I/O calls from the signal
> handler.  That's something I'm planning to do at one point, but
> don't hold your breath.

You may be able to configure the timeout response on the device to
reduce the wait.  Beyond that we are at the mercy of Windows.

-- 
cyg Simple

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

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

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

On Jan 12 11:47, cyg Simple wrote:
> On 1/12/2017 10:00 AM, Corinna Vinschen wrote:
> > On Jan 11 19:13, L. A. Walsh wrote:
> >> 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.
> > 
> > Exactly.  The hanging call is just some NtOpenFile call on the
> > filesystem.  The timeout is an unfortunate effect of accessing
> > a remote drive.  One problem here is that Cygwin doesn't support
> > interrupting of synchroneous Windows I/O calls from the signal
> > handler.  That's something I'm planning to do at one point, but
> > don't hold your breath.
> 
> You may be able to configure the timeout response on the device to
> reduce the wait.

How so?  If it requires changing the registry it's not something
Cygwin can do on the fly without admin consent.  Only if we can
define a timeout on the application level we could use it.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[cyg Simple]

On 1/12/2017 1:51 PM, Corinna Vinschen wrote:
> On Jan 12 11:47, cyg Simple wrote:
>> You may be able to configure the timeout response on the device to
>> reduce the wait.
> 
> How so?  If it requires changing the registry it's not something
> Cygwin can do on the fly without admin consent.  Only if we can
> define a timeout on the application level we could use it.

I meant the OP on his own system.  Network timeouts are configurable but
YMMV with those changes staying between reboots.  I don't see this as a
Cygwin issue but an environment one.

-- 
cyg Simple

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