On another note: I just backported an upstream fix for a race condition.
Might be related to this issue or might not. Please try to test with
latest trunk or bb-branch.
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
htt
No, miniupnp doesn't use procd yet. However you should be able to use the
usual: ulimit -c unlimited somewhere above the service_start call to enable
core dumps.
On 19. August 2014 19:15:32 MESZ, "Luis E. Garcia" wrote:
>I've noticed this issue with dnsmasq, I think that miniupnp is also
>havin
I've noticed this issue with dnsmasq, I think that miniupnp is also having
a similar issue where it dies silently after a few days.
Can I apply the same method to debug miniupnp ??
Regards,
Luis Garcia
On Tue, Aug 19, 2014 at 10:45 AM, Bastian Bittorf
wrote:
> * Steven Barth [19.08.2014 12:49
* Steven Barth [19.08.2014 12:49]:
> procd_set_param limits core="unlimited"
thanks, this works fine here when the 'root' part of
dnsmasq gets a -SIGSEGV (or during a real crash) and
produces coredumps. i will keep the list updated,
when i catch a real hang.
bye, bastian
Hi Bastian,
you should try:
procd_set_param limits core="unlimited"
Cheers,
Steven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
On 19 August 2014 12:10, Bastian Bittorf wrote:
> sometimes dnsmasq 2.71 (trunk) dies silently but
> the process is still running. when sending:
>
> kill -SIGSEGV $PID
>
> there is no coredump but the daemon gets restarted (via procd?)
> normally inserting 'ulimit -c unlimited' just before startin
sometimes dnsmasq 2.71 (trunk) dies silently but
the process is still running. when sending:
kill -SIGSEGV $PID
there is no coredump but the daemon gets restarted (via procd?)
normally inserting 'ulimit -c unlimited' just before starting
the daemon should be enough, but i'am unsure how to apply,
