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

[Victor Duchovni]

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...

> 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 :-(

-- 

 /"\ ASCII RIBBON                  NOTICE: If received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and notify
  X AGAINST       IT Security,     sender. Sender does not waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or privilege,
                                   and use is prohibited.