From owner-freebsd-arch@FreeBSD.ORG Mon Dec 8 14:18:04 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7240ED0D for ; Mon, 8 Dec 2014 14:18:04 +0000 (UTC) Received: from testsoekris.hotsoft.nl (unknown [IPv6:2001:888:1227:0:200:24ff:fec9:5934]) (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 28DFA948 for ; Mon, 8 Dec 2014 14:18:03 +0000 (UTC) Received: from beastie.hotsoft.nl (beastie.hotsoft.nl [IPv6:2001:888:1227:0:219:d1ff:fee8:91eb]) by testsoekris.hotsoft.nl (8.14.7/8.14.7) with ESMTP id sB8EI0vc063301; Mon, 8 Dec 2014 15:18:00 +0100 (CET) (envelope-from hans@beastielabs.net) Message-ID: <5485B318.3030402@beastielabs.net> Date: Mon, 08 Dec 2014 15:18:00 +0100 From: Hans Ottevanger User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Process reapers References: <20141201185237.GC97072@kib.kiev.ua> In-Reply-To: <20141201185237.GC97072@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 14:18:04 -0000 On 12/01/14 19:52, Konstantin Belousov wrote: > Please find at https://www.kib.kiev.ua/kib/reaper.6.patch > the patch which adds a way for the process to declare itself a reaper > for the subtree of processes forked after the event. In other words, > after the process is marked as reaper, all orphaned children somewhere > in subtree after the reaper, are reparented to the process instead of > init(8). > > The API is based on the following DragonFlyBSD commit > http://gitweb.dragonflybsd.org/dragonfly.git/commit/fc3bc2868ad212f3b412ad13f0eaa35b3f8d458d > Linux has somewhat similar prctl(PR_SET_CHILD_SUBREAPER). > Solaris is most advanced in the area, the feature which provides > the same function is contracts(4), which is very advanced and > IMO over-designed interface. > > I did not wrote the man page, the API is still in flux. It should > be relatively clean how to use the thing by the descriptive names > and comments in header file. One of the test programs illustrating > the interface is available at https://www.kib.kiev.ua/kib/reaper2.c . > See http://leaf.dragonflybsd.org/cgi/web-man?command=procctl§ion=2 > for the description of DragonFly interface. > > The feature was requested by bapt, jilles already provided useful > feedback that was incorporated into the patch. > > Please review and comment. I gave your patch a try over the weekend (I had to reassemble a system and install 11-CURRENT for testing and that took a while.) The test program you provided demonstrates quite clearly what is intended and it also functions well. First thing I asked myself was: what happens if the reaper dies? What I see happening is that the reaper of the dead reaper becomes the reaper of its process subtree. The new reaper will often be init but it is also possible it is another process and that sounds OK. Concerning the API: The call of procctl() with subcommands PROC_REAP_ACQUIRE, PROC_REAP_RELEASE and PROC_REAP_STATUS all require a pid_t as second argument that -must- be the current process id, as obtained by getpid(). As far as I can see procctl() returns an error otherwise, so the pid argument seems a bit superfluous. Is it absolutely required to use procctl() for this functionality? Isn't a separate system call for process reaping a better solution? Second, the PROC_REAP_GETPIDS command indeed provides a snapshot of the subtree at the moment procctl() is called but on a busy system many processes are created and go away, so this is very dynamic information. I wonder what you expect to do with this call. As far as I know PROC_REAP_KILL is the first facility apart from kill(2) that signals a collection of processes. Isn't there a way to incorporate it in kill(2). I have no idea what you (or bapt@) are planning to do with this reaper stuff, maybe you could share a bit more detailed information about your goals. Kind regards, Hans