[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2010-03-28 Thread Alex Denvir
We are closing this bug report because it has not been updated for some time. Please reopen it if you have more information to submit, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the

Re: [Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-14 Thread Charles Lepple
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

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-13 Thread Martin Pitt
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? If it works with 2 and not with 1, there's something wrong in the

Re: [Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-10 Thread Arnaud Quette
@Charles: /etc/nut/nut.conf is available and used as of 2.4.1-2, both in Debian (Sid) and Ubuntu (Jaunty). @Martin: if you want to have the full framework running, without having a real UPS, you might want to give a try to dummy-ups. For an example use, look at:

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-10 Thread Martin Pitt
I tested it on jaunty; I currently don't have a hardy install (just chroots, but there I can't test kernel stuff), but if necessary I'll install it. However, the kernel side for catching core dumps, and the apport side of getting them fed into the kernel didn't change since hardy. -- apport

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-09 Thread Martin Pitt
Indeed. You said that /var/crash/ was empty, so it can't be a previously existing crash either. I installed nut, changed /etc/nut/nut.conf to say MODE=netclient, and created a default upsmon.conf. That gives me two upsmon processes; I kill -SEGV'ed one of them, and duefully got an apport crash

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-09 Thread Charles Lepple
Martin, I apologize for making things confusing. Let me try and simplify it somewhat: tripplite_usb and bestups are two of the hardware-specific drivers, and they won't stick around if the corresponding hardware (old Tripp-Lite gear, or Best Power, respectively) isn't present on the system. So

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-06 Thread Martin Pitt
Then these programs most likely intercept crashes on their own, so that the kernel doesn't use the default core dump exit route. Could you please try the following: - find out the pid of any of those programs (e. g. /lib/nut/bestups) with ps aux | grep bestups - sudo strace -o /tmp/trace -p

Re: [Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-06 Thread Arnaud Quette
Hey Martin, 2009/3/6 Martin Pitt Then these programs most likely intercept crashes on their own, so that not at all. the driver signal handler is the following: static void setup_signals(void) { struct sigactionsa; sigemptyset(sa.sa_mask); sa.sa_flags =

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-05 Thread Martin Pitt
Can you please try to fake a crash with sudo killall -SEGV tripplite_usb and then attach /var/log/apport.log here? ** Changed in: apport (Ubuntu) Status: New = Incomplete -- apport doesn't seem to catch a SIGSEGV in NUT https://bugs.launchpad.net/bugs/240565 You received this bug

[Bug 240565] Re: apport doesn't seem to catch a SIGSEGV in NUT

2009-03-05 Thread Charles Lepple
The hardware for tripplite_usb isn't hooked up to that computer at the moment, but I tried simulating a crash on /lib/nut/bestups, /lib/nut /usbhid-ups, /sbin/upsd and /sbin/upsmon. None of those generated any output in /var/log/apport.log Just to see if apport was working, I killed