On Mar 13, 2009, at 4:42 PM, Martin Pitt wrote: > Hm, I'm at the end of my wisdom here as well. Perhaps you can try > starting ups with ulimit -c unlimited, so that you'll get core files? > (1) does that work with apport enabled? (2) does that work after sudo > /etc/init.d/apport stop?
Some interesting results: * Clean boot, new shell with 'sudo -s' * Killed driver started by /etc/init.d/nut and upsdrvctl * Ran 'ulimit -c unlimited' * Verified that this worked by checking /proc/self/limits * with apport running, started driver by hand: su -c '/lib/nut/ bestups -a ppro2' -s /bin/sh nut * killall -SEGV bestups * Crash report in /var/crash, no core in /var/run/nut * Stopped apport, verified that /proc/sys/kernel/core_pattern was simply "core" * restarted driver by hand * killall -SEGV bestups * no crash report, core in /var/run/nut As I understand it, this is the expected result. While I was performing this test, I realized that /etc/init.d/nut was starting the driver via /sbin/upsdrvctl. New shell, apport started: * ulimit -c unlimited * /sbin/upsdrvctl start ppro2 # the 'ppro2' config section specifies 'bestups' as the driver * Verified that driver started. * killall -SEGV bestups * No crash report; no core file (unexpected) * Stopped apport * /sbin/upsdrvctl start ppro2 * killall -SEGV bestups * No crash report (expected); no core file (also unexpected) Here is the portion of code that corresponds to starting the driver: http://boxster.ghz.cc/projects/nut/browser/tags/v2.2.1/drivers/ upsdrvctl.c#L236 As you can see in the forkexec() function, the only special case for signal handling is in the parent upsdrvctl process, which does not stick around once the driver has started successfully. -- apport doesn't seem to catch a SIGSEGV in NUT https://bugs.launchpad.net/bugs/240565 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
