delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2024/06/17/04:06:24

DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 45H86Nxq2106524
Authentication-Results: delorie.com;
dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=w/qDF9bW
X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1B9F2385C6CD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
s=default; t=1718611582;
bh=YiqsPE/vs469pn7e5ZJdzi4Li+Fv994Zu6MhM4thlgs=;
h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
From;
b=w/qDF9bWxir3cIpwnMF2klX4K8bD/fb8elu61kj/vQKzeVjXfLuQ4aM5GkgBZohga
h1aGssmDEz9Xd7zY2m6yU1JpkKlkFPo7E4V45Hz2Ftxbx9Vb1/vz5mlxnbY4BlLd1s
GGcmy8j33r2+DsCZdBowLMcdHR1Bbq8Twrqjg0z4=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D7403857C4F
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3D7403857C4F
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1718611510; cv=none;
b=T9lhu7ndrxUVZAZXJ8rvZsd6LREwFi5CgDKiWMMGpbUUtHjAyrZDleTSVRvkO2cLKbis+RAeDi/PtZs5TPJzzE6yLh2zzMBnOXlvwVhwMge4tUUIPQ3zR6G6e64+G5qAdfD2etRBrv3y355cbyUpr/0iRKyaqLkZwFyjGU3YhVs=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
t=1718611510; c=relaxed/simple;
bh=fcrZDLHmRveVgyslV0qWlpFA5wPePUWZuOU1DqE0mNo=;
h=DKIM-Signature:Date:From:Message-ID:To:Subject:MIME-Version;
b=BoDin/sxopoA9HQvfeXb0Q6nV5/uZreA4aC0ULdVsqNMtVI9QcMnPUh+B3YpqyBIG6+/QjCR/p8TJo62Gesio66VAJ7DSYj7vdX25dU8Zb7UnT8zQy0AcmHCKFDiCGkfuot+BlxtvsAkVCj2XDYxDsuxspjec7rZfnQpb0RoaAY=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Yandex-Fwd: 1
Date: Mon, 17 Jun 2024 10:58:08 +0300
X-Mailer: The Bat! (v9.3.4) Professional
Message-ID: <1399464798.20240617105808@yandex.ru>
To: Nicholas Williams <nicholas DOT williams AT zaxiom DOT com>, cygwin AT cygwin DOT com
Subject: Re: Cygwin outputting message to stderr on dofork EAGAIN failure even
when Python exception is caught and handled
In-Reply-To: <DC419F64-5E24-493F-AFB7-9B31062A3FB6@zaxiom.com>
References: <DC419F64-5E24-493F-AFB7-9B31062A3FB6 AT zaxiom DOT com>
MIME-Version: 1.0
X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00, DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_THEBAT,
NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
TXREP, T_SCC_BODY_TEXT_LINE,
XM_LIGHT_HEAVY autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Andrey Repin via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Andrey Repin <anrdaemon AT yandex DOT ru>
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 45H86Nxq2106524

Greetings, Nicholas Williams!

> We have a Python (installed and run through Cygwin) process running on
> Windows Server 2022 that was very, very occasionally failing when subprocess.check_output was called:

> 0 [main] python3 28481 dofork: child -1 - forked process 16856 died
> unexpectedly, retry 0, exit code 0xC0000142, errno 11
> …
>     subprocess.check_output(["cygpath", "-w", directory.name], encoding="utf-8").strip()
> File "/usr/lib/python3.9/subprocess.py", line 424, in check_output <>
>      <>return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, <>
> File "/usr/lib/python3.9/subprocess.py", line 505, in run <>
>      <>with Popen(*popenargs, **kwargs) as process: <>
> File "/usr/lib/python3.9/subprocess.py", line 951, in __init__ <>
>      <>self._execute_child(args, executable, preexec_fn, close_fds, <>
> File "/usr/lib/python3.9/subprocess.py", line 1754, in _execute_child
>     self.pid = _posixsubprocess.fork_exec(
> BlockingIOError: [Errno 11] Resource temporarily unavailable

> Setting aside for a minute the various reasons this might be happening
> occasionally, which we cannot solve for at this moment, the error number
> (EAGAIN) indicates that you should “try again.” So that’s exactly what we
> did. We added a try/catch to the Python code to catch the BlockingIOError
> and, if and only if the error number is EAGAIN, we try up to two more times.
> This fixed the problem and caused the application to stop quitting. We
> output a warning to our log so that we don’t forget about the problem, but
> the warning only ever appears once, so retrying a single time seems to help.

> However … even though Python handles the dofork error, turns it into a
> Python exception, and our code catches the Python exception and handles it
> properly, Cygwin (not Python … Cygwin) still outputs a message to stderr
> right before our warning message. This Cygwin error message shows up as an error in our log tracking:

> 0 [main] python3 15042 dofork: child -1 - forked process 6780 died
> unexpectedly, retry 0, exit code 0xC0000142, errno 11
> 06/16 13:57:53. 87520: WARNING: Retrying command in 2 seconds due to EAGAIN: [the command we’re running]

> I’m sure there could be any number of things I might be missing, but IMO,
> if the process calling dofork properly handles the error raised by dofork,
> Cygwin should not be outputting an error message to stderr.

> Thoughts?

My inexperienced and uneducated thought would be that forking code is fragile
and some parts of it prone to misbehavior. When an unforeseen error is
detected, it's better to report it sooner, than to get bitten by it later.

Regarding your specific issue, if you create a STC[1] (a minimally enough
version of your code that, say, fork a process thousands of times, which
reliable reproduce the issue) somebody else could run to test the cause, that
would be wonderful.

(If, however, you could find and fix the cause, that would be even more wonderful!)

[1] https://www.cygwin.com/acronyms/#STC


-- 
With best regards,
Andrey Repin
Monday, June 17, 2024 10:52:05

Sorry for my terrible english...

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019