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=DhhQdcdHH1+Ws4QaPPmCkEM85VqaXcqHMx40JACCiz6
	ApdulZUhtRH/OdUgvmQ+KquomwIQFmkir4WR/FxT795UJUMdeBRqe2wpgHvyGRXe
	xBVXr10o6XZhuxaa46YdOKB5K4xYZO0gj2YWQMBTr0n+KK5Ne1LVCD3VEkuDO6TU
	=
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=PuwbYRrqQ3Ygnz4l7Jbm7Mh10GE=; b=i8mYxVUCSYOiD/dKn
	vtAp/Nbnfn39rdc22CaOJHr5iCdcdCRznvxD4FnVHmASwxsvVgBLGougPjf5AFDj
	m87VuWvW4RvimjiL84BiwmaXcfdAd6fWUKYzlnVx2mRg7vPUYv+XdFAnHN5ExB8A
	UGuCubE2iXsYErVy2on49M52fc=
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.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=exhibit, H*RU:sk:omr-a01, Hx-spam-relays-external:sk:omr-a01, H*i:sk:9619f42
X-HELO:	omr-a015e.mx.aol.com
Message-ID:	<581B3ECE.1030000@verizon.net>
Date:	Thu, 03 Nov 2016 09:42:38 -0400
From:	Gerry Reno <greno AT verizon DOT net>
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Windows 10 updates causes fork retry no child processes
References:	<581A0AA5 DOT 5030107 AT verizon DOT net> <0d98a082-e270-659f-5b48-b9dfd01fc85f AT SystematicSw DOT ab DOT ca> <581AD3D3 DOT 2020908 AT verizon DOT net> <9619f42f-e8c8-c48c-fd6d-48e8bf33789d AT SystematicSw DOT ab DOT ca>
In-Reply-To:	<9619f42f-e8c8-c48c-fd6d-48e8bf33789d@SystematicSw.ab.ca>
x-aol-global-disposition:	G
x-aol-sid:	3039ac1afe6e581b3ecf00d7
X-AOL-IP:	47.196.166.20
X-IsSubscribed:	yes

On 11/03/2016 09:00 AM, Brian Inglis wrote:
> On 2016-11-03 00:06, Gerry Reno wrote:
>> On 11/03/2016 01:06 AM, Brian Inglis wrote:
>>> On 2016-11-02 09:47, Gerry Reno wrote:
>>>> Is there some automated way I can stop Windows 10 updates from
>>>> continuously causing these fork retry no child process issues after
>>>> every damn update?
>>>> We use an application based on Cygwin (2.6.0) on our clients that
>>>> gets wrecked everytime a Windows 10 update occurs.
>>>> The users have no idea about Cygwin because it's hidden from them so
>>>> I cannot ask them to do anything with regard to Cygwin.
>>>> Any ideas for an automated way to stop these errors would be
>>>> appreciated.
>>> Could be caused by changed addresses used by Windows dlls, especially
>>> if you are using the limited address space of Cygwin32.
>>> After each update, have you tried shutting down all Cygwin processes
>>> and either running setup unattended, if you sometimes do that, or a
>>> full rebase from a cmd script?
>>> For example:
>>> c:\cygwin64\bin\dash /bin/rebase-trigger fullrebase
>>> c:\cygwin64\bin\ash /bin/rebaseall
>>> You can check if an update has been performed by caching and comparing
>>> the timestamp and/or name of the last update log saved:
>>> $ ls -lt --time-style=long-iso \
>>> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20??????.??????.???.?.etl \
>>> | head -n 1
>>> e.g.
>>> -rwxr-x---+ 1 SYSTEM SYSTEM  77824 2016-11-02 22:27
>>> /proc/cygdrive/c/Windows/Logs/WindowsUpdate/WindowsUpdate.20161102.214528.076.1.etl
>>> and checking whether a restart has been been performed since to apply
>>> the update by comparing against the output of:
>>> $ date -d "now - `cut -d' ' -f1 /proc/uptime` seconds" +'%F %R'
>>> e.g.
>>> 2016-10-22 19:44
>>> in this case indicating Windows has not been (auto)restarted since
>>> the update.
>>> If you don't use mintty, you could do this in an ash or dash script
>>> at Windows login, which does the rebase-trigger then exec rebaseall,
>>> so no other process is running using Cygwin.
>>> If you use Cygwin mintty you would have to do the equivalent from a
>>> cmd or PowerShell script before launching any Cygwin process.
>>> If your client systems run Windows Enterprise or Education or use
>>> SCCM instead of Windows Update, details may need to be changed.
>> The users cannot do anything with Cygwin.
>> And the client machines are out in the field and not even connected
>> to a network.
>> What is needed is for Cygwin itself to detect and manage the
>> situation.
>
> Myself and others are not seeing these specific problems every update.
> You may want to try following the problem reporting guidelines for help.
>
> You need to see if you can diagnose and fix these problems in the
> clients' environment by getting access and trying disabling or
> deinstalling BLODAs or running rebaseall.
>
> If you can do that, you can try patching setup, or writing scripts,
> to provide a fix.
>
> Finally, you can try submitting those patches upstream to Cygwin for
> inclusion in setup, or as a separate package performing the fix.
>

We are only seeing this on the newer W10 machines.
W8 machines don't exhibit this problem.
And both have the exact same set of software installed on them.
So there must be something different about W10.


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

- Raw text -