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=COTe3bmGtIkoyIg92Ah5vajmhuqVlRRyQj3lgHqj+2q
	N6f04tm1gtWBgExrQI1QscfPxL1Q9oayzJrjct/nmbIBj34yZG8820GsliA5fCv0
	zF/warl5nRGQY9R0vMiFZsmmdyIalyS9uwM/d+QrwQ0Ma6kVHtSwBARwqZZCTofM
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <581AD3D3.2020908@verizon.net>
Date: Thu, 03 Nov 2016 02:06:11 -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>
In-Reply-To: <0d98a082-e270-659f-5b48-b9dfd01fc85f@SystematicSw.ab.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.


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