X-Recipient: archive-cygwin AT delorie DOT com
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=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default; bh=0+jq0POs6vGryt7l5IDPmi
	Oqrak=; b=kQJlcnVJGJzzUB9BcH+9b2Bj7yRCvnUB2opaMNdgtE+rJrMoSRbapY
	Ud+yyMdKctTq0OQ4mwRV7JJ3CY/7VNGs7phkeTf+xPwx+2R0it7cESOJS5dpZkA/
	EuAjZVFknrSKM9BnuRllKbgKKTex7YBBmWuNqPZIU+Ma0m+M4GYik=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=mercy, Beyond, Hx-languages-length:1992, planning
X-HELO: mail-it0-f48.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:subject:to:references:from:message-id:date         :user-agent:mime-version:in-reply-to:content-transfer-encoding;        bh=q4zTakNrRtGhSj03McQgZtL5OV9TRL15mY6LVo0ZaxQ=;        b=bMWZFo3Ke1wZhhdnf8u2kDL1lvDg5XFhPYdGDUvj0Y0wkVWwnW6wabSM1bgvOC3/iH         z3UBhuXarRvJYMuoHze1aQD0ztQdkcYn3mJqn2oTuab6BkhXg7vlZ1JBp/YfSg4A7hH7         Wpqvo17EXPgM3TrgVdIqHYddS0GyXOiAYMGthLS3QJ0K3NTF8h4tTI54TVvvIkVAWGxt         pK1Xidyza4IvaYN3SUS3pnf6uNKo5ltN7pfOmSB94KcLq3N5JlUu0v4PrvKkbPLYYopx         tsUwSNk0Zp4nS9wPm/ad9S9mosDBjOpOZQopLHb/ZPg+ehpRlAWNeWH1FDqTEwo076Yb         x23Q==
X-Gm-Message-State: AIkVDXKOSvYUdoldF4PKUCzHjhYk36FI6nRx/VqIaNFRAqdxAw7+wEhMJoR88t+Zx/+Wjg==
X-Received: by 10.36.79.71 with SMTP id c68mr14764264itb.47.1484239625691;        Thu, 12 Jan 2017 08:47:05 -0800 (PST)
Subject: Re: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system
To: cygwin AT cygwin DOT com
References: <5875B7F6 DOT 8090406 AT tlinx DOT org> <20170111201635 DOT GA29910 AT calimero DOT vinschen DOT de> <5876F43E DOT 7010608 AT tlinx DOT org> <20170112150050 DOT GB12383 AT calimero DOT vinschen DOT de>
From: cyg Simple <cygsimple AT gmail DOT 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
X-IsSubscribed: yes

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