From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 07:38:20 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 517D8325; Sat, 19 Apr 2014 07:38:20 +0000 (UTC) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1024F1767; Sat, 19 Apr 2014 07:38:19 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s3J7IfAL093043; Sat, 19 Apr 2014 00:18:45 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201404190718.s3J7IfAL093043@gw.catspoiler.org> Date: Sat, 19 Apr 2014 00:18:41 -0700 (PDT) From: Don Lewis Subject: Re: Process handlers, and zombies, or preap(1) To: bsd-lists@bsdforge.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-hackers@FreeBSD.org, hackers@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2014 07:38:20 -0000 On 1 Apr, Chris H wrote: >> On Monday, March 31, 2014 4:06:43 pm Chris H wrote: >>> Greetings, >>> I'm evaluating/experimenting on releng_9. The install, and now >>> custom kernel have noting exotic, or anything out of the ordinary. >>> top(1), and ps(1) indicate a (1) zombie, or process. On >>> my releng_8 systems, when I occasionally encounter one of these, >>> they soon disappear (are reaped) from the process table. While I >>> have not investigated this far enough on both versions to determine >>> whether the parent process reaped the child on the releng_8 systems, >>> and the parent on releng_9 is simply an irresponsible parent, eg; >>> a different parent. Before I do, I was wondering if there was any >>> specific difference between the 2 versions that might cause better >>> handling of such situations. While I recognize that resource >>> starvation is HIGHLY unlikely, except by perhaps a rouge parent >>> spawning multitudes of zombies. I thought it might be useful for >>> "housekeeping" to 1) provide a process table housekeeper (zombie >>> reaper), or 2) create a system utility/command like SunOS/OpenSolaris >>> has; preap(1). >>> >>> http://www.freebsd.org/cgi/man.cgi?query=preap&manpath=SunOS+5.10 >>> >>> Thank you for your time, and consideration. >> >> Nothing is different with child processes in 9 vs 8. It is most >> likely a misbehaving parent (or the parent is stuck or hung). > > Hello, John, and thank you for the reply. > Right you are. Julian Elischer was kind enough to remind me that > ps -alx > would give me the information I needed to find the seemingly > "lazy" parent process. But not before I had already (re)created > a (Free)BSD version of preap(1), and cleared the entry from the > proc table. > However, it re-appeared again. So this time I traced it to it's > parent, and now I can deal with it /properly/. It's an old port > who's development was taken over by a Windows developer. So he > doesn't have access to the *NIX-isms. I'll see if I can find > the time to coordinate some effort(s) to clean it up, or branch > a NIX version. A call to signal(SIGCHLD, SIG_IGN); would probably fix the problem with no fuss. From the signal(3) man page: If a process explicitly specifies SIG_IGN as the action for the signal SIGCHLD, the system will not create zombie processes when children of the calling process exit. As a consequence, the system will discard the exit status from the child processes. If the calling process subsequently issues a call to wait(2) or equivalent, it will block until all of the calling process's children terminate, and then return a value of -1 with errno set to ECHILD.