On Mon, 23 Jul 2012, Matthijs Mekking wrote:
When issuing a "sign zone" command, the signer will go to a couple of
locks:
- - zonelist lock (zl_lock): to look up the zone. zonelist unlock.
- - zone lock (zone_lock), schedule lock (schedule_lock): to reschedule
the zone task. schedule unlock, zone unlock.
The zl_lock and schedule_lock shouldn't be locked that long.
The zone_lock can take up an considerate amount of time: It is used
when signing the zone (read in file, update nsec records, sign zone,
write out file). Could it be that you issue the command during the
time the signer is busy with these tasks? How long does it normally
take to sign the zone (from reading in to writing out)?
the total working signing process takes about 5 minutes. We've seen
the lock for 20-40 minutes.
If this sounds plausible, I think we can fix this by splitting the
lock: One for updating the task and zone , one for fiddling with the
zone contents.
Should I be able to see if it is in this state by the presence of tmp/*
files? Or is the lock logic perhaps somehow using/stalling on those
tmp/* leftovers? (I'm not sure what is cause and effect here)
I could do some testing for you if you have a patch (though there will
prob be some delays due to IETF84)
Paul
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
