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

[Michael Tokarev]

Victor Duchovni wrote:
> On Wed, Apr 27, 2005 at 09:39:22PM +0400, Michael Tokarev wrote:
> 
>>And yes, atomic updates it a must.  I was thinking about this scenario:
>>somewhere in the file header, have a flag, say, "active".  Main rbldnsd
>>process checks the flag (mmaped) on each query, and peforms the reload
>>if it's zero.  And the "builder" process does the following:
>>
>>  prepare_new_file(file.tmp);
>>  fd = open(file);
>>  rename(file.tmp, file);
>>  pwrite(fd, 0, 1, offsetof(active_flag));
>>
> 
>     /* The locking code, must stat(2) the file after
>        obtaining the lock, to make sure it has not moved */
>     fd = prepare_new_locked_file(file.tmp);
>     ... populate and flush tmpfile ...
>     pwrite(fd, 0, 1, offsetof(active_flag)); /* mark active */
>     fsync(fd);	/* Force all data and metadata to disk */
>     rename(file.tmp, file); /* Rename with lock still held */
>     close(fd);	/* This releases the lock */
> 
> The file must be crash-proof once it is marked active. The version
> you suggest is not atomic, but the idea is the same...

Crash-proof?  You mean, to stay after power failure for example?
It's easy to achieve by running something during startup -- to
force re-create the file for example.

And, the version I suggest (or thought anyway) *is* atomic -- the
file.tmp is created (in prepare_new_file()) with active=1, it is
the *old* (now, after rename(), deleted) file which gets updated
to have active=0.

I personally don't see any reasons to do locking either.. because
on all my systems (and surprizingly, I use rbldnsd on several
high-volume servers - c.ns.dsbl.org and j.ns.dsbl.org are two
my machines, all mirrors dsbl, cbl and spamhaus, and c.ns also
mirrors ahbl), I use external tools to do locking around the
whole rsync/update procedure.  With this tiny program (surprize
again, I haven't found anything like it on the 'net) --
http://www.corpit.ru/mjt/lckdo.c

But that's all are details, details... ;)

>>But all this is a theory for now.  We're having quite.. significant probs
>>with dsbl nameservers for example, -- reloading 6M+ entries even as
>>ip4tset takes quite some time and requires quite some memory, ...
>>Ofcourse this whole prepare-binary-image process isn't needed at 99%
>>sites using rbldnsd, -- the ones who're dealing with smaller amounts
>>of data...
> 
> I have a list.dsbl.org feed, so I have the same issue :-(

Which issue do you have?  DSBL.org nameservers have quite strong
constraints over data "freshness" - the data should be max 3 minutes
old (rsync every single minute; note we aren't rsyncing the whole
6M entries each time, we're rsyncing *-fresh files that often, and
that files are *much* smaller).  When the server is slow enouth
(600MHz celeron is like nothing these days), and the amount of data
is that large, it can't complete the full resync+reload in 3 minutes
(funny enouth, it's rsync which is taking most of that time, not
rbldnsd reloading).

With faster hardware and less load (j.ns performs about 4.5Kqps now),
this should be a non-issue really.  Still, binary data will be
significantly smaller (I want that binary format to be portable
between different architectures) than text form...  but not necessary
faster for rsync because of different change distribution.

Note all dsbl.org nameservers are running with -f (fork on reload)
option enabled.  Except of linux signal handling idiocy, there was
no single prob so far... ;)

/mjt