From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63489 invoked by alias); 17 Feb 2017 22:06:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 63473 invoked by uid 89); 17 Feb 2017 22:06:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*Ad:U*mark, doh, zombie, d'oh! X-HELO: m0.truegem.net Received: from m0.truegem.net (HELO m0.truegem.net) (69.55.228.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Feb 2017 22:06:04 +0000 Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id v1HM63ZY059646 for ; Fri, 17 Feb 2017 14:06:03 -0800 (PST) (envelope-from mark@maxrnd.com) Received: from 76-217-5-154.lightspeed.irvnca.sbcglobal.net(76.217.5.154), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdJU5D4e; Fri Feb 17 14:06:01 2017 Subject: Re: Problem with zombie processes To: cygwin@cygwin.com References: <58A3598F.2020405@maxrnd.com> From: Mark Geisert Message-ID: <58A773C9.1080905@maxrnd.com> Date: Fri, 17 Feb 2017 22:06:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00222.txt.bz2 Erik Bray wrote: > On Tue, Feb 14, 2017 at 8:25 PM, Mark Geisert wrote: Please don't quote raw email addresses. We try to avoid feeding spammers. >> Erik Bray wrote: >>> >>> The attached Python script >> >> ?? > > D'oh! Here is the script. It at least demonstrates the problem. > [...] Thanks! Running this script repeatedly on my system (Win7, 2 cores / 4 HT threads) showed no differences between your Test 1 and Test 2. Each Test concludes in one of three ways, seemingly randomly: (1) read of /proc//stat succeeds and process status is displayed, (2) read fails with Python IOError, (3) read apparently succeeds but there's no process data displayed. An strace of your script shows Python itself is calling wait4() to reap the child process. So, as Doug suggested on another thread, the script's actions are just subject to the whims of process scheduling and vary from run to run. ..mark -- 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