delorie.com/archives/browse.cgi | search |
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:message-id:date:from:mime-version:to:subject | |
:references:in-reply-to:content-type:content-transfer-encoding; | |
q=dns; s=default; b=MDdx0lzViDuZFa0pyo1p6sHtxNo0a1f8esKcqBefWKN | |
HUIL9d6gTSZMorOqTvEFG7wjSN96lSsoJeFb7GQ7biv0Kn8PEzNSvKPU5WWWAWXQ | |
jNeYSwRglLz23jS9VICOKgvdVGUSq9XZd0AxqmamXmVuDy3rdMAQItq7wLHok7Y0 | |
= | |
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:message-id:date:from:mime-version:to:subject | |
:references:in-reply-to:content-type:content-transfer-encoding; | |
s=default; bh=eaos4XCXXcQ9/3lBHqvn811Ky+E=; b=aJAEnO9p1e8vP9GE9 | |
rQx7YkUFKymewM03r6HbVPuJ8vt4DCfJJ+VvV/zbSl4JiqKjHbOadrInxL04LZyr | |
cT+gCwTHkpkwAIqUY4HE5ZUglHQvq0jSfG1vZtJ8SBbgvxuHw05Z8QvejzV1JPYl | |
J19cejlazEQnuG+xAWzzdt6OPc= | |
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=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=idle, Hx-languages-length:2371, secs, letter |
X-HELO: | Ishtar.sc.tlinx.org |
Message-ID: | <5876F43E.7010608@tlinx.org> |
Date: | Wed, 11 Jan 2017 19:13:02 -0800 |
From: | "L. A. Walsh" <cygwin AT tlinx DOT org> |
User-Agent: | Thunderbird |
MIME-Version: | 1.0 |
To: | cygwin AT cygwin DOT com |
Subject: | Re: hang on 'cat /proc/mounts' when one of the network drives is on a 'down' system |
References: | <5875B7F6 DOT 8090406 AT tlinx DOT org> <20170111201635 DOT GA29910 AT calimero DOT vinschen DOT de> |
In-Reply-To: | <20170111201635.GA29910@calimero.vinschen.de> |
X-IsSubscribed: | yes |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |