The crash it self is not a segfault of what I can see.<br><br>I test it by running it in "monitor" mode and suddenly it just drops back to the shell.<br>It might indeed be solved by your latest patch - I would gladly test it.<br>

<br>Greetings,<br><br clear="all">Christian "BC" Svensson<br>Codelead Systems - <a href="http://www.codelead.se">http://www.codelead.se</a><br>
<br><br><div class="gmail_quote">On Tue, Jul 21, 2009 at 10:27 PM, Norbert Sendetzky <span dir="ltr"><<a href="mailto:norbert@linuxnetworks.de">norbert@linuxnetworks.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im">On Mon July 20 2009 11:01:05 you wrote:<br>
> Yes, updating only one zone at the time is very much acceptable - that the<br>
> initial transfer takes quite long time does not matter.<br>
><br>
> We do not want to use an "active" database due to memory / CPU footprint.<br>
> If PowerDNS locks the table and let the other threads just wait for the<br>
> lock like any other mutex it would probably be just fine with<br>
> distributor-threads = 1.<br>
<br>
</div>The problem of the SQLite database is that while a zone transfer is in<br>
progress, all other threads can't serve any records. This is because the<br>
complete table is locked by SQLite when records are updated and this also<br>
prevents reading records in other zones. Please keep this in mind for your<br>
installation.<br>
<div class="im"><br>
> I want to note that indeed PowerDNS _crashes_ / _exits_ in the end due to<br>
> the "Database is locked" error. Since I'm currently testing with OpenDBX I<br>
> don't know íf this is something that is regarded as an OpenDBX or PowerDNS<br>
> bug - but gsqlite3 did also crash during heavy load which (as stated<br>
> before) makes me believe that it's backend agnostic.<br>
<br>
</div>What you've shown me in your logs is that the PowerDNS opendbx backend gets an<br>
error from the SQLite library that the database is locked and the opendbx<br>
backend forces the distributor thread to recreate the connection to the<br>
database. The problem is that the sqlite3 backend of the OpenDBX library<br>
returns a fatal error when the database is locked instead of a timeout. This<br>
is fixed in the SVN trunk and the fix will be also be included in OpenDBX<br>
1.4.2. The next problem is that the PowerDNS opendbx backend doesn't make use<br>
of timeouts at the moment and treats them as errors. I've already enhanced the<br>
PowerDNS opendbx backend but I have to test it as soon as I can and see if the<br>
problem is gone. I will create a patch and send it to you so you can test<br>
yourself.<br>
<br>
What I haven't seen in your log file excerpt is that the opendbx backend<br>
crashed with a segfault.<br>
<div><div></div><div class="h5"><br>
<br>
Norbert<br>
--<br>
OpenPGP public key<br>
<a href="http://www.linuxnetworks.de/norbert.pubkey.asc" target="_blank">http://www.linuxnetworks.de/norbert.pubkey.asc</a><br>
<br>
<br>
</div></div><br>_______________________________________________<br>
Pdns-users mailing list<br>
<a href="mailto:Pdns-users@mailman.powerdns.com">Pdns-users@mailman.powerdns.com</a><br>
<a href="http://mailman.powerdns.com/mailman/listinfo/pdns-users" target="_blank">http://mailman.powerdns.com/mailman/listinfo/pdns-users</a><br>
<br></blockquote></div><br>