While attempting to upgrade my "hacking" SKS key server today,
I noticed this looping behavior:
How I screwed up my key server isn't really the issue, note "hacking" please.
There was identifiable b0rkage with db_verify, and several upgrade <-> downgrade
cycles across different versions of Berkeley DB, all dealt with "By The Book"
as in running Berkeley DB utilities to "fix" issues. But I digress ...
The loop is occurring with this failure message(s) in db.log:
2010-05-02 15:46:47 Del'ng hash FF7B1F647DC91CC96269026442970C63
2010-05-02 15:46:47 add_keys_merge failed: Bdb.Key_exists
2010-05-02 15:46:47 Key addition failed: Bdb.Key_exists
2010-05-02 15:46:54 Handling /pks/hashquery
2010-05-02 15:46:54 63 keys found
IMHO, add_keys_merge should undertake some corrective action so that sks servers
and keep on running, and committing rather than discarding the transaction update,
rather than endless attempting the same (failing) update.
YMMV: one can also be "strict" and demand FULLSTOP, never RESTART until
problem is repaired by sysadmin manual intervention, behavior.
But looping endlessly on updates is the real flaw with daemons/servers, not
how the problem occurred, or how the flaw should be remedied.
Downloading keydumps to start "afresh" in progress ...