Collectd dns plugin issue

hnyman · January 9, 2025, 6:51am

It has never worked ok in the openwrt context.
Even if you manage to configure it right, it will likely crash.
There is likely a threading race inside collected core - DNS plugin - pcap - something, which causes a crash.
(and as there is currently no real upstream development of collectd, the problem will not disappear)

See

I debugged it extensively in

github.com/collectd/collectd

DNS plugin in 5.5.0 segfaults under Linux 4.1.x

opened 12:54PM - 16 Aug 15 UTC

closed 05:12PM - 05 Apr 18 UTC

hnyman

Bug Pending contributor action

I have built identical builds for Openwrt router (ar71xx / mips32r2 / WNDR3700) …with Linux kernel 3.8.x and 4.1.x, and collectd 5.5.0 segfaults quickly with Linux 4.1.x if the dns plugin is enabled. If DNS plugin is disabled, collectd works otherwise normally also with 4.1.x. The plugin works ok with Linux 3.8.x. Segfault: ``` [ 104.435977] [ 104.435977] do_page_fault(): sending SIGSEGV to collectd for invalid write access to 76db3ae8 [ 104.444585] epc = 76f6ef30 in dns.so[76f6e000+14000] [ 104.449597] ra = 0040f084 in collectd[400000+30000] [ 104.454602] ``` I have opened an issue at the Openwrt bug tracker ( https://github.com/openwrt/packages/issues/1660 ), but I am opening also this issue here as this sounds more like an collectd problem due to some change at Linux.

Also with the current collected 5.12

github.com/collectd/collectd

DNS plugin segfaults - OpenWRT / kernel 4.14

opened 05:53PM - 26 Dec 20 UTC

Strykar

* Version of collectd: `5.12` * Operating system / distribution: `OpenWrt 1…9.07.4 r11208-ce6496d796` * Kernel version (if applicable): `4.14.195 #0 SMP x86/64 Linux` ## Actual behavior Given enough time running, the DNS plugin will segfault and crash, shutting down collectd. ``` Sat Dec 26 14:14:48 2020 daemon.err collectd[17396]: dns plugin: pcap_loop exited with status -1. Sat Dec 26 14:15:13 2020 kern.info kernel: [103791.357292] reader#0[17408]: segfault at 7f4142f1a758 ip 00007f414313519a sp 00007f4142f1a760 error 6 in dns.so[7f4143135000+2000] Sat Dec 26 14:15:13 2020 daemon.info procd: Instance collectd::instance1 s in a crash loop 6 crashes, 271 seconds since last crash ``` I have opened https://github.com/openwrt/packages/issues/14339, but the maintainer suggested this should be reported upstream. This behavior has been going on for a long time even in previous versions on OpenWRT. The OpenWRT package maintainer tried to help debug it in the past but that did not appear to go anywhere and the issue was closed. See https://github.com/collectd/collectd/issues/1227 the issue seems to be related to the DNS plugin using libpcap. Issue is not platform specific (I have know of this issue for years on x64) and the maintainer was troubleshooting this on ar71xx / mips32r2 architectures. The current workaround suggested for OpenWRT is to [disable the plugin](https://forum.openwrt.org/t/collectd-dns-plugin-crashes/20386/2) as its crashing causes collectd to exit. ## Steps to reproduce * Install and enable collectd on OpenWRT. * Wait 10 - 90 mins * View syslog to confirm collectd has crashed While I could provide debug logs, I am not half as competent as @hnyman and his attempts in https://github.com/collectd/collectd/issues/1227 Perhaps OpenWRT could be added to Collectd's test suite as this issue is easily reproducible?

And here the same recent in our packages repo issues:

github.com/openwrt/packages

collectd-mod-dns segfaults after running a while

opened 09:32AM - 26 Dec 20 UTC

closed 05:07AM - 14 Jan 21 UTC

Strykar

@hnyman / `19.07.4 r11208-ce6496d796 on x86/64 ` The `collectd-mod-dns` plugin… runs fine for a while and then segfaults. ``` Sat Dec 26 14:14:48 2020 daemon.err collectd[17396]: dns plugin: pcap_loop exited with status -1. Sat Dec 26 14:15:13 2020 kern.info kernel: [103791.357292] reader#0[17408]: segfault at 7f4142f1a758 ip 00007f414313519a sp 00007f4142f1a760 error 6 in dns.so[7f4143135000+2000] Sat Dec 26 14:15:13 2020 daemon.info procd: Instance collectd::instance1 s in a crash loop 6 crashes, 271 seconds since last crash ``` I recall this happening even on `18.x`, I suppose the next step is to take debug logs, but I'm unsure if this is the correct place or if this should be reported upstream?