Date: Mon, 8 Dec 2014 16:42:30 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Hans Ottevanger <hans@beastielabs.net> Cc: arch@freebsd.org Subject: Re: Process reapers Message-ID: <20141208144230.GU97072@kib.kiev.ua> In-Reply-To: <5485B318.3030402@beastielabs.net> References: <20141201185237.GC97072@kib.kiev.ua> <5485B318.3030402@beastielabs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 08, 2014 at 03:18:00PM +0100, Hans Ottevanger wrote: > 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. RIght, this is intended behaviour. > > 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? REAP_STATUS does not require the pid to be equal getpid(). I used the procctl(2) since this syscall was intended as administrative control over process facility, and reaper is exactly this sort of thing. IMO adding new syscall for reaping is overkill, e.g. Linux uses its analog of procctl (prctl AFAIR) for the same purpose. Requiring pid for two rarely used (at the start and at the end of being reaper) points of reaper life is fine from my PoV. What I apparently dislike from the current procctl(2) interface is the lack of the integer argument along the pointer. I.e. now I would prefer a signature similar to ptrace(2). Go know when single-use procctl(2) was added. > > 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. REAP_GETPIDS return a list with two kinds of pids. One kind is just pid of a process in the descending tree of subprocesses. There is nothing much you could do with the pid except showing it to user, similarly to ps(1). Other kind if pid of the child process, marked with the corresponding flag in the list. Since the pid of child is sort of handle in the parent process, you can do interesting things with it, e.g. killing certainly correct process, or wait(2) for it. Note that any descendant is either killed and reaped by its parent, or is re-parented ot the reaper, which makes it child of the reaper. This allows for reaper to kill all the tree in race-free manner, guaranteeing that no runaway process was left. The non-children pids are useful for informational purposes, to explain the state to the user, from the orchestrator. Think about batch runners, like port building tools, which allow reliable termination of the builds, without jailing. > > 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 am not sure what you propose. kill(2) and killpg(2) have defined semantic, I do not see how could kill(2) can incorporate the tweaky behaviour of the REAP_KILL. > > 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. It was requested by bapt, who could explain it further. As I understand, port bulk builds and utilities like timeout(1) are to use the facility.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141208144230.GU97072>