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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=JQB4p4+k7Rz5TwfNeNgbnHFGP8KOHTWuYkge+c+xyCIYfmjSn71Dl
	FE5rnKzgfs+gbggd+hB0bVu02v66tXJrAomzVcj/oYl19UfEFH0e+htZgFFn+vri
	3Uha9bd4Yp8TIfqm7r5dknewAMdcv/5BR667e+Rs1b3c6O8/QlVgMo=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=kO2k1VwEnzM322QD6+a2w5HSAkg=; b=L0wQ8TU047xjLMqcpWC1J2SC9sWK
	AGYEL5NWDNQisqVfn3gd/o6j3eMeKL2Bgl3gbtdX7Mqwc5kphvSmqCbtJjRFPWRb
	odXyg5SA8A50XH2QnM/qEQMrP/u7WuqY0o2M7SAdlUERvUHZMUpAULfnvvYPs92D
	Ndz2hO/yuYOx/bA=
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=-101.6 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=consent, fly, H*f:sk:cedfb8b, H*i:sk:cedfb8b
X-HELO: drew.franken.de
Date: Thu, 12 Jan 2017 19:51:44 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system
Message-ID: <20170112185144.GC23119@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-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> <cedfb8ba-0907-6323-530e-933360782d23 AT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="mvpLiMfbWzRoNl4x"
Content-Disposition: inline
In-Reply-To: <cedfb8ba-0907-6323-530e-933360782d23@gmail.com>
User-Agent: Mutt/1.7.1 (2016-10-04)

--mvpLiMfbWzRoNl4x
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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).  Giv=
en
> >>> that, apart from C: maybe, the drive letter mapping can change any ti=
me,
> >>> Cygwin doesn't cache the information but requests it every time it ne=
eds
> >>> it.  This includes information required in /proc/mounts, here basical=
ly
> >>> 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.
> >=20
> > 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.
>=20
> 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

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

--mvpLiMfbWzRoNl4x
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYd9BAAAoJEPU2Bp2uRE+gAwoP/3WYtdDCRb6zoP9Vbt0KlV3p
qcOIsZE7nWM2IhGt8tmIAn65gAp5IolPGhFNeT2aatZaSXiWr5aOZPcmYqLWyqVj
/Ng8/7ER2/KMnJ+//FLv0XIda+LwcZ/5RXkZTj8T/GGtgAwFumt/rQRc56ypfL5h
7mROvOh+y+Cat9I4quTWAnpGAUBIW+AklXpz3iYIJk7T+GEqtQrezJ+bHvEriFLJ
Sv5X3J2IbhAOP8vAD0ZA78FLsk3kWSdsC4IFBNG5wbo+mriMGu6TqkGp2AaCjw0T
aFyTVFt7HCcpD8wQq/J8Z0RkFsHUD+0kfRP5en5W8lOEnPnII81YTmabMQ+6/MAW
oWdqyOaYm27ddajJzNGk0xWmcrBzIZLBundYyQ+IAJX3UmwWdDxfgyE9gi6yineg
krLGEwOATSikNCpH16tEmSXstjtLQBY3cI41jGX/lY7D9JYFikieK4jzcSc2MMSS
Z/mB7eAQGPl+ah89qQgG7pLWMavTLYtmYAfibf0s60vfiuQW44OdSJN8PVYvKlk8
rwrNRTL/VzK5jEmQZdRrKrTcf6DXsKxTGSAQoTRnBdTq3BHU866dGgxkROlFyJIB
aZSzgQzw89VuDqGphtTWARKMCyUJk1GYDgEOpn2kJ13le6Fgjjnn01+mGuMY7kpw
WXaJHguxXM0fDRiGKoJH
=/JSJ
-----END PGP SIGNATURE-----

--mvpLiMfbWzRoNl4x--