On Tue July 28 2009 16:33:28 you wrote:
> It might indeed be solved by your latest patch - I would gladly test it.
Sorry, I wasn't able to test the patch I've written in detail but maybe it
already solves your problem. You must use it in combination with the latest
version of OpenDBX from the SV
The crash it self is not a segfault of what I can see.
I test it by running it in "monitor" mode and suddenly it just drops back to
the shell.
It might indeed be solved by your latest patch - I would gladly test it.
Greetings,
Christian "BC" Svensson
Codelead Systems - http://www.codelead.se
O
On Mon July 20 2009 11:01:05 you wrote:
> Yes, updating only one zone at the time is very much acceptable - that the
> initial transfer takes quite long time does not matter.
>
> We do not want to use an "active" database due to memory / CPU footprint.
> If PowerDNS locks the table and let the othe
We had this problem too when we moved all domains to pdns (hidden master
on mysql, multiple sqlite3 slaves ). The crash happened when I
'notified' about 40 domains simultaneously for the initial transfer.
See http://mailman.powerdns.com/pipermail/pdns-users/2008-April/005287.html
Since then pdns
On Mon, Jul 20, 2009 at 11:01 AM, Christian Svensson wrote:
> Yes, updating only one zone at the time is very much acceptable - that the
> initial transfer takes quite long time does not matter.
>
> We do not want to use an "active" database due to memory / CPU footprint. If
> PowerDNS locks the ta
Yes, updating only one zone at the time is very much acceptable - that the
initial transfer takes quite long time does not matter.
We do not want to use an "active" database due to memory / CPU footprint. If
PowerDNS locks the table and let the other threads just wait for the lock
like any other m
On Sun July 19 2009 19:21:56 bert hubert wrote:
> > SQLite is only useful for small installations and a few domains because
> > it uses table locks when it writes the changes to the database. As each
> > zone
>
> That may be so, but it should still not crash.
Like I wrote to Bert in a private mail
On Sun, Jul 19, 2009 at 2:15 PM, Norbert
Sendetzky wrote:
> Hi Christian
>
>> After combating some weird incompatibility with Debian Lenny 5.0 where
>> PDNSs gsqlite3 refused to write anything to the database it begun to crash
>> when we did the initial transfer (notify of several hundred domains).
Hi Christian
> After combating some weird incompatibility with Debian Lenny 5.0 where
> PDNSs gsqlite3 refused to write anything to the database it begun to crash
> when we did the initial transfer (notify of several hundred domains).
> I have tried with the OpenDBX backend which seems to work muc
It is able to write to the database a couple of times - and I know it has
permissions to both write to the file and create it's journal file in the
same directory. Heck, the directory and files are owned by pdns so it can do
whatever it desires.
Christian "BC" Svensson
Codelead Systems - http://ww
Very quick reply without thinking, make sure PowerDNS has write
permissions on the *directory* containing the sqlite3 database - this
tends to trip people up 'it can write to the file' is not enough.
I'll read your message more carefully to see what else might be happening.
Bert
On Sat, Jul
Hello.
We are trying to migrate from bind9 to PowerDNS.
We have our back-end supermaster successfully constructed using PowerDNS +
postgresql 8.3 + alsonotify-patch (http://wiki.powerdns.com/trac/ticket/216)
The slaves have to have a very small footprint and therefore we have chosen
sqlite3 as our
12 matches
Mail list logo
