[Opendnssec-user] signer: "assertion part->soamin failed"

[Matthijs Mekking]

Hi Havard,

On 11-12-15 17:03, Havard Eidnes wrote:
> Hi,
> 
> we have recently been plagued by this particular assertion
> being triggered in the signer.  The logged message is:
> 
> Dec 11 15:13:52 xxxxx ods-signerd: signer/ixfr.c:230: part_print: assertion part->soamin failed
> 
> When this is logged, that's the last we hear from ods-signerd,
> i.e. it exits.
> 
> Can someone familiar with this piece of code please explain what
> problem this assertion might indicate?  The text in the log
> message itself isn't very descriptive.  Looking at the code this
> appears to be related to use of IXFR, but I can't figure out the
> sequence of events which might trigger this problem, or where the
> data parts would come from (DNS neighbor? Already-existing IXFR
> log?)

An IXFR message is a list of differences between two versions of a zone.
In OpenDNSSEC this is called parts.

A part is a list of deleted records and a list of added records. THE SOA
record in these lists are kind of special and are stored separately. The
soamin is the SOA record that is deleted, the soaplus is the SOA record
that is added.

If one of those SOA records is missing in the part, then there is
something broken, and we fail on the assertion.

Where the data part comes from: Evertime a change is made we keep a
journal in the working directory: <zone>.ixfr. That is read out when the
secondary requests an IXFR from OpenDNSSEC.


> Having assertions fire in long-running daemons in a normal
> operational environment is a bug, plain and simple.

I agree, however for a developer the assertion helps to find the actual bug.


> When this happens, if we try to restart the signer, it will
> shortly thereafter exit again with the same message; I have then
> to remove the tempoary files and push new zone content via notify
> messages from the hidden master to set things up again.  So, this
> time I have two sets of such files which I can supply to a
> developer who would be willing to take a closer look (if indeed
> the source of the data can be found in the files on disk).

The contents of the backup files may help, because as you say,
restarting will give you the same error. That tells me that reading the
soamin from backup fails, so that file should be able to be used to
trigger the bug.

There aren't many lines that alter soamin.


Best regards,
  Matthijs


> Again, OpenDNSSEC version is 1.4.7 with the hopefully unrelated
> changes discussed earlier, and pulling and pushing via zone
> transfers to BIND 9.9.7-something.
> 
> Best regards,
> 
> - Håvard
> _______________________________________________
> Opendnssec-user mailing list
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
> 

_______________________________________________
Opendnssec-user mailing list
Opendnssec-user at lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user