Re: Respawn limit for runsv?

[Lars Kellogg-Stedman <lars@oddbit.com>]

> > There is no general class of problem unless you can provide a single
> > instance.

Seriously, I would like to live in your perfect world, but in the past 
couple of decades I've seen a variety of situations that would have been 
easier to deal with (or that, in fact, *were* easier to deal with) 
because of a limiter.  Let's make up some examples:

- A piece of hardware on which a program depends goes bad, causing the 
program to exit immediately upon startup.  Suppose that this program has 
a high initial startup cost -- so not only is it respawning pointlessly, 
but it's driving up system load.

- The disk fills up, causing your X startup to fail.  But because of the 
continuous respawning, you can't log in on the console!

- A program bug causes a crash and concomitant database corruption.  
Subsequent startups fail immediately, but since you're logging through 
svlogd, the original crash messages disappears into the ether because 
the roughly 3600 respawns/hour have pushed it out of the logs.

- Or in any of the above scenarios, maybe you're *not* logging through 
svlogd, and the error messages fill up a partition and bring the system 
to a screeching halt, or at least give it a noticeable limp.

Sure, yes, the root problem here is not unlimited respawning, but this 
behavior exacerbates the problem.  Diagnosis and resource consumption 
are both aided by some sort of limit.

Exponential back-off would probably be just fine, and represents a 
fairly common solution to this class of problem.  SysV init simply 
pauses for a few minutes if the respawn rate exceeds a certain 
threshold, and then tries again.

Either behavior would be helpful.  If you've never encountered a 
situation in which this would be useful, then by all means, don't 
partake of whatever, if anything, I ultimately manage to produce.