[Opendnssec-user] Immediate sign & locking issue (1.4.0a2)

[Siôn Lloyd]

On 29/06/12 21:19, Sander Smeenk wrote:
> Hi,
>
> when i add a zone to ODS i want it signed on disk immediately.
> This is why i currently add zones with this command sequence:
>    ods-ksmutil zone add $zone
>    ods-ksmutil update zonelist
>    ods-signer sign $zone
>
> I started developing with ODS1.3.2 and it would sometimes bail on the
> ods-signer command if i did not run the 'update zonelist' immediately
> after adding a zone. I recall 'zone not found' errors.
> It was reproducable and the zonelist update fixed it back then.
>
> With 5 zones this is all nice but with plenty more zones
> the 'update zonelist' command takes quite some time to complete.
> Or is it the enforcer?
>
> The enforcer seems to be triggered through the 'update zonelist'
> command to process *all* the zones, not just the recently added one.
> This seems to introduce a deadlock situation if the enforcer finds KSKs
> to be published, executes <DelegatedSignerSubmitCommand> and the
> <DSSubCmd> itself wants to use ods-ksmutil to look up stuff.
> This situation seems to locks up tight on my setup on kasp.db.lock.
>
> Oddly, if the normal scheduled enforcer run publishes DS through the
> exact same <DSSubCmd> this seems to work just fine...
>
> Is ODS not designed to do immediate sign after add or am i messing
> things up here? Should i run something else to satisfy conditions for
> the sign call? My config is in sqlite3 and stored on an NFS mount, as
> are all the (un)signed zones. Would switching to MySQL improve this
> situation at all?
>
>

Hi Sander,

the current enforcer has no facility to process just a single zone, so 
as you point out the update makes it process all the zones that it knows 
about.

There is some code which should make it in to both the 1.4 and 1.3 
branches which will relieve the deadlock by having ods-ksmutil only try 
getting a database lock for a minute before returning. This would mean 
your DSSubCmd failing, which is not ideal either.

Revisiting the sqlite locking requirements is something on our radar, 
assumptions were made at the start of the project which may not valid 
any more.

Using MySQL should fix the issue, we do no locking then.

Sion