[rbldnsd] Idea for cleaning up forked child when reloading parent dies

[Michael Tokarev]

Victor Duchovni wrote:
> Currently, when forking for reloads, the child process could be stuck
> forever with stale data. We can make use of the fact that when the

Hmm.  In which situation that can happen?  I mean, why the parent should
ever exit?  Crash?  Or just SIGTERM?

If it's the latter, and granted, I don't remember how this situation is
handled currently, it should be easy to fix (modulo the stupid linux
behaviour).  If it's the former.. well, yes, the problem is real.

> parent process is killed, the status report pipe is closed. If the child
> selects for read on the status report pipe, it can exit as soon as the
> pipe becomes readable. I don't have a patch handy, but this should not
> be too difficult...

I wanted to avoid usage of select() if at all possible (ofcourse it is
still here when more than single listening socket is specified).  The
reason for that is simple: here's a vmstat output from j.ns.dsbl.org
aka ns6-cbl.abuseat.org aka t.ns.spamhaus.org:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
  2  0   5496  47804  18700  89896    0    0     0    35 8260 13404  7 23 71  0
  2  0   5496  47804  18700  89896    0    0     0     0 8355 13616  5 21 74  0
  2  0   5496  47800  18704  89896    0    0     0     1 8481 13787  6 21 73  0
  2  0   5496  47800  18704  89896    0    0     0     1 8161 13410  8 17 75  0
  2  0   5496  47800  18704  89896    0    0     0     0 8243 13590  3 20 77  0
  2  0   5496  47796  18708  89896    0    0     0     1 8275 13379  6 20 74  0
  2  0   5496  47796  18708  89896    0    0     0     0 8391 13824  5 22 74  0
  2  0   5496  47784  18720  89896    0    0     0     6 8128 13338  6 21 74  0
  2  0   5496  47764  18732  89904    0    0     0    26 8094 13129  3 20 77  0
  2  0   5496  47764  18732  89904    0    0     0     0 8126 13183  4 16 80  0
  2  0   5496  47764  18732  89904    0    0     0     1 7828 12979  4 19 76  0
  2  0   5496  47764  18732  89904    0    0     0     0 8107 13293  3 18 79  0

Note the amount of context switches (this is 600MHz Celeron).  Adding select in
between means two more switches per query...

I'm thinking about using a sort of binary on-disk format like DJB's rbldns does,
this should eliminate the need for forking altugether.  Dunno if it's a right
way, but it should help for large lists like dsbl.org.

/mjt