DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=eILtKgXu13IdUPOF
	CgB1dbX2APcQskY+UdQl4hQvKrX03jgn50e22QTc17tFGupqLG3Lu7QzZH6y2TLL
	FkPUIiRBsw1WMzmDzAYcRzEXEj88HSRwTNhGBySK+8Bz/ZFkC6zmEw/O8nKMmNVD
	54ziLvK6ruNLZmnKL2R+XhKu8Z8=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system
To: cygwin@cygwin.com
References: <5875B7F6.8090406@tlinx.org> <20170111201635.GA29910@calimero.vinschen.de> <5876F43E.7010608@tlinx.org> <20170112150050.GB12383@calimero.vinschen.de>
From: cyg Simple <cygsimple@gmail.com>
Message-ID: <cedfb8ba-0907-6323-530e-933360782d23@gmail.com>
Date: Thu, 12 Jan 2017 11:47:02 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170112150050.GB12383@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

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