Re: posible bug in daemontools

Thus said Mark Johnson on Mon, 22 Mar 2010 00:13:10 CDT:

> True.  Hmmmm. What  about something  like the  quadratic backoff  from
> qmail? Would that strike a better balance between the two extremes?

I don't think the question is the rate at which the daemon is respawning
(if that were the case a simple sleep as is found in qsutils.c's nomem()
and pausdir() would likely be  sufficient; supervise does actually sleep
already at  this point I believe),  but rather the futility  of doing so
when  there  is  an  inimical  agent attempting  to  randomly  kill  off
processes. I suppose a flag which allowed administrators to choose which
behavior should be used would be  nice. Maybe this option already exists
with  the use  of DIR/down  and  svc -o?  In  which case,  the patch  is
likely harmless since  administrators already have this  option at their
disposal.

Maybe it isn't possible to distinguish between the case where the system
is out of memory and an agent is acting against the supervise process to
start new  processes, in  which case,  it is probably  best to  not make
assumptions and continue respawning.

> I think some  sort of failed fork recovery is  necessary, otherwise on
> the rare occasion  when the OOM killer actually whacks  the memory hog
> causing the problem, you're left with  a functional system with a down
> service. 8)

What if the memory hog is a supervised process? :-)

Andy
-- =

[-----------[system uptime]--------------------------------------------]
 11:38pm  up  5:13,  1 user,  load average: 1.22, 1.14, 1.10