Date: Mon, 08 Dec 2014 15:18:00 +0100 From: Hans Ottevanger <hans@beastielabs.net> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org Subject: Re: Process reapers Message-ID: <5485B318.3030402@beastielabs.net> In-Reply-To: <20141201185237.GC97072@kib.kiev.ua> References: <20141201185237.GC97072@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5485B318.3030402>