Re: [announce] perp-2.03: persistent process supervision

[Laurent Bercot <ska-supervision@skarnet.org>]

> First, perpd(8) will not die (TM).

 Of course it will not - not in normal circumstances.
 Neither will svscan, or runsvdir, or s6-svscan.
 I trust your programming ability in that matter as much as mine - this
is not a concern at all.

 The concern is that you don't always have the say. There's this playful
thing called the Linux OOM killer. I hear the heuristics have been fixed
in recent kernel releases, but for a long time, the OOM killer had the
amusing habit of shooting processes at random, and very much failing to
locate the process that is actually responsible for the memory outage.
 There are still a whole lot of broken OOM killers out there.

 Of course, this is not a normal condition, and under careful administration
it never happens. But the point is, when you are designing a supervision
tool, you should assume that you can get a random SIGKILL (Headshot. Do
not pass Go. Do not call your cleanup routines.) at any time.

 Because if a supervision tool can't recover from an OOM event and keep
vital services running until the sysadmin finishes his coffee and can
manually repair things, then what is it good for ?

 That is why I asked my question. In other supervision schemes, tasks are
de-centralized, so if one process randomly dies, it generally does not have
much impact on the rest of the system. (If runsvdir dies, it's annoying,
but things keep working until the admin can come clean things up.)
 perpd, however, looks like a neural hub, centralizing a lot of info into
its memory. IOW, a SPOF, and you can be sure that the next broken system
tool will love to play Doom with it.

 Is your supervision chain SIGKILL-resistant ?

-- 
 Laurent