Re: subreapers

From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_NTLWorld.com>
Date: Sun, 11 Dec 2016 18:00:46 +0000

What M. Misuth is doing is the most imaginative use of local reapers
that I have come across. What I wrote in the nosh doco back in version
1.0 was:

> This yields a slightly more informative process tree.

This was presented as a mere side-effect by Poettering and Sievers in
2012. The main idea was a rather vague, and in the end not implemented,
notion that user instances of systemd could somehow make use of the fact
that they were made the parents of orphaned grandchildren processes in
order to Do Stuff. In fact, it is the mere side-effect that turns out
in practice to be the major benefit.

You should not underestimate how useful the effects on the process tree
are. All service manager instances in nosh are local reapers, and one
sees the effects with the system-wide service manager as well as with
per-user service managers. One doesn't see such a pronounced effect
with the system-wide service manager because, as I have noted elsewhere
in this thread, as a result of the pressure from the daemontools world
for the past two decades the world already makes the process tree of
system-wide service management fairly well organized. Lots of daemons
do not fork-and-exit-parent any more, and orphaned grandchildren simply
do not arise as much in this area as they used to at the turn of the
century.

But the effect for per-user stuff is marked.

This is because the world of per-user stuff includes "desktop services",
like the roughly ten servers that have to be started up in order to run
the "small and lightweight" GNOME Editor. This world is still replete
with things that fork-and-exit-parent. To give another example: The
PCDM startup of X desktop environments on TrueOS (formerly PC-BSD)
starts up a whole bunch of user processes via fork-and-exit-parent.
These all end up in a different part of the process tree to the desktop
processes sitting under the top-of-desktop-session process, under
process #1 or the nearest local reaper. In the output of "ps -dax", all
of these processes are scattered all over the shop.

One can improve this subtree with broken branches all over the forest
floor with a local reaper.

The benefit of local reapers is not a programmatic one for the likes of
you and me. It is a usability one for administrators and end users
trying to follow their process trees.
Received on Sun Dec 11 2016 - 18:00:46 UTC