[LEDE-DEV] dnsmasq: please revert/disable "dhcp-script" feature by default

Dirk Brenken dev at brenken.org
Thu Jun 1 08:07:09 PDT 2017


Hi Jo,

many thanks for the links - very interesting.
Meanwhile I've received three bug reports from adblock users, that they
get oom errors after the "dhcp-script" commit
(https://git.lede-project.org/?p=source.git;a=commit;h=b32689afd6a66133
9861086c669e15c936293cf8), e.g.

Tue May 30 10:20:09 2017 daemon.crit dnsmasq[1911]: failed to create
helper: Out of memory
Tue May 30 10:20:09 2017 daemon.crit dnsmasq[1911]: FAILED to start up
Tue May 30 10:20:18 2017 daemon.crit dnsmasq[1921]: failed to create
helper: Out of memory
Tue May 30 10:20:18 2017 daemon.crit dnsmasq[1921]: FAILED to start up
Tue May 30 10:20:27 2017 daemon.crit dnsmasq[1922]: failed to create
helper: Out of memory
Tue May 30 10:20:27 2017 daemon.crit dnsmasq[1922]: FAILED to start up
Tue May 30 10:20:36 2017 daemon.crit dnsmasq[1923]: failed to create
helper: Out of memory
Tue May 30 10:20:36 2017 daemon.crit dnsmasq[1923]: FAILED to start up
Tue May 30 10:20:45 2017 daemon.crit dnsmasq[1924]: failed to create
helper: Out of memory
Tue May 30 10:20:45 2017 daemon.crit dnsmasq[1924]: FAILED to start up
Tue May 30 10:20:54 2017 daemon.crit dnsmasq[1925]: failed to create
helper: Out of memory
Tue May 30 10:20:54 2017 daemon.crit dnsmasq[1925]: FAILED to start up
Tue May 30 10:20:54 2017 daemon.info procd: Instance dnsmasq::cfg02411c
s in a crash loop 6 crashes, 4 seconds since last crash

For testing, I've asked these users to comment the following line in
/etc/init.d/dnsmasq and to restart dnsmasq and adblock afterwards.

#       xappend "--dhcp-script=$DHCPSCRIPT"

After that change everything is working fine again, as long as only one
instance of dnsmasq runs.

Please advice - many thanks!
Dirk



Am Sonntag, den 28.05.2017, 21:59 +0200 schrieb Jo-Philipp Wich:
> Hi Dirk,
> 
> the info reported by "top" (or "ps") is not useful to judge effective
> process memory usage, it does not account for c-o-w and simply displays
> the entire virtual allocated memory by a process.
> 
> When I was asking for specific evidence I was thinking along the lines
> of OOM conditions that didn't happen before the change and other similar
> symptoms like that.
> 
> Unfortunately the LEDE kernels do not provide /proc/$pid/smaps
> information which would make tracking actual memory usage way simpler
> but here's some useful links nonetheless which explain the topic a bit
> further:
> 
> https://serverfault.com/questions/440115/how-do-you-measure-the-memory-footprint-of-a-set-of-forked-processes
> 
> https://jameshunt.us/writings/smaps.html
> 
> Regards,
> Jo
> 
> _______________________________________________
> Lede-dev mailing list
> Lede-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev



More information about the Lede-dev mailing list