[Pdns-users] v3.0.1 + MySQL + OpenSuSE 12.1

[Peter van Dijk]

Hello Rick,

On Jan 31, 2012, at 13:57 , Rick Hodger wrote:

> I’m in the process of upgrading our servers and I’ve come across a curious problem. Our old servers are openSuSE 11.x and running Power DNS v2.9 quite happily, but I’m struggling to get 3.0.1 to work on OpenSuSe 12.1.
>  
> The RPM version exits with a segmentation fault and nothing we do seems to be able to get it work short of removing the MySQL config.

Our static RPM does not work everywhere, especially not on very recent distributions. We're working on providing better packages by default.

> Jan 31 12:47:43 radius pdns[6135]: Got a signal 11, attempting to print trace:
> Jan 31 12:47:43 radius pdns[6135]: pdns_server() [0x4bdec2]
> Jan 31 12:47:43 radius pdns[6135]: /lib64/libc.so.6(+0x34e10) [0x7f6e5d788e10]
> Jan 31 12:47:43 radius pdns[6135]: /usr/lib64/libmysqlclient.so.18(my_stat+0x6c) [0x7f6e5ed82d0c]
> Jan 31 12:47:43 radius pdns[6135]: /usr/lib64/libmysqlclient.so.18(+0x4b054) [0x7f6e5ed7e054]
> Jan 31 12:47:43 radius pdns[6135]: /usr/lib64/libmysqlclient.so.18(my_search_option_files+0x264) [0x7f6e5ed7ee84]
> Jan 31 12:47:43 radius pdns[6135]: /usr/lib64/libmysqlclient.so.18(my_load_defaults+0x13b) [0x7f6e5ed7f1eb]
> Jan 31 12:47:43 radius pdns[6135]: /usr/lib64/libmysqlclient.so.18(mysql_read_default_options+0x74) [0x7f6e5ed65f24]
> Jan 31 12:47:43 radius pdns[6135]: /usr/lib64/libmysqlclient.so.18(mysql_real_connect+0x8d) [0x7f6e5ed6794d]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN6SMySQLC2ERKSsS1_tS1_S1_S1_+0xc9) [0x45c379]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN13gMySQLBackendC1ERKSsS1_+0x148) [0x455608]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN13gMySQLFactory4makeERKSs+0x35) [0x45bc15]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN17BackendMakerClass3allEb+0x167) [0x4a8137]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN12UeberBackendC2ERKSs+0x14c) [0x4c1c9c]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN13PacketHandlerC1Ev+0x1c) [0x480d9c]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server(_ZN17CommunicatorClass8mainloopEv+0xaa) [0x4ea28a]
> Jan 31 12:47:43 radius pdns[6135]: pdns_server() [0x4eab29]
> Jan 31 12:47:43 radius pdns[6135]: /lib64/libpthread.so.0(+0x7f05) [0x7f6e5daeaf05]
> Jan 31 12:47:43 radius pdns[6135]: /lib64/libc.so.6(clone+0x6d) [0x7f6e5d82d53d]
>  
> Curiously though, if we start it in non-demon mode it actually manages to get going and begins answering queries, but only after it logs about a gazillion “gmysql Connection successful” lines. This is the tail end of the output after about 20-30 seconds of the same line being logged over and over.
>  
> Jan 31 12:40:26 gmysql Connection successful
> [..]
> Jan 31 12:40:26 gmysql Connection successful
> Jan 31 12:40:26 [bindbackend] Done parsing domains, 0 rejected, 15829 new, 0 removed
> Jan 31 12:40:26 gmysql Connection successful
> Jan 31 12:40:26 gmysql Connection successful
> Jan 31 12:40:26 About to create 1 backend threads for UDP
> Jan 31 12:40:26 No new unfresh slave domains, 0 queued for AXFR already
> Jan 31 12:40:26 gmysql Connection successful
> Jan 31 12:40:26 gmysql Connection successful
> Jan 31 12:40:26 Done launching threads, ready to distribute questions
> Jan 31 12:40:26 No master domains need notifications
>  
> Any help or ideas would be appreciated.

I have no immediate explanation for the difference you are seeing in daemon vs. non-daemonmode. The sheer amount of gmysql connections can probably be explained from your config. Feel free to post your config if you would like additional explanation.

Kind regards,
Peter van Dijk