Process reapers

[Hans Ottevanger]

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&section=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