Re: [Sks-devel] sks-peer.spodhuis.org catching back up

[Jeffrey Johnson]

On May 29, 2012, at 4:43 PM, Kim Minh Kaplan wrote:

> Phil Pennock :
> 
>> I'd tried to make sksclient be read-only in BDB access, but failed to
>> find a way to do so because a directory-based BDB *always* seems to use
>> log files.  So I'd given up and gone with the flow.
>> 
>> Apparently the locking is not what it could be, as I ended up with a DB
>> that needed recovery.  Moral 1: do not run sksclient against a serving
>> DB.
> 
> SKS opens its environment with Dbenv.RECOVER flag¹. This is nice to ease
> restarting after a crash. But this is wrong when multiple processes are
> accessing the environment at the same time². Jason Harris reported that
> he removed Dbenv.recover and that it permits him multiprocess access to
> the key databases³.
> 

All processes sharing a dbenv WILL see the same DB_RECOVER. There's
also means to signal all other processes through a dbenv as well.

The part that is missing in sks (affair: I haven't looked at OCAML for ~2y) the
part that is missing is a simple retry on the dbenv open if/when
the DB_RUNRECOVERY is returned.

(aside)
A full blown implementation might attempt restart on every occurrence
of DB_RUNRECOVERY and restarting/replaying the request in progress.
But that's hardly necessary for two daemons running, a simple 1 attempt
to fix and reopen the dbenv is all that is needed.

The automated DB_RECOVER works fine with RPM databases that are fully ACID and
in a much more rugged environment than SKS key servers.

hth

73 de Jeff
> Kim Minh.
> 
> ¹ keydb.ml line 326.
> ² http://docs.oracle.com/cd/E17276_01/html/api_reference/C/envopen.html
> ³ http://lists.nongnu.org/archive/html/sks-devel/2009-08/msg00015.html
> -- 
> Kim Minh
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel