@Christophe Lohr (#17) - See bug 1153662 Core file not created on
SIGQUIT, for which a fix has been released.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/62511
Title:
dumps core on SIGQUIT
To
Hi,
Todays Apport (2.0.1) filters core dump on SIGQUIT. I'm not sure it is a good
choice.
The excuse put forward is that SIGQUIT is usually deliberately generated by
users.
And then?
Sure, SIGQUIT is deliberately generated by users. Users may deliberately do
want a core-dump of a process.
Right (gosh, I barely remember this ancient bug). Apport should not
generate a report on SIGQUIT, but if ulimits allow, it should write a
core file.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/62511
However, this bug is for something different, so if it doesn't write a
core file properly, please file a new report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/62511
Title:
dumps core on SIGQUIT
Flipping back to Invalid as noted by Ben.
** Changed in: linux (Ubuntu)
Status: Confirmed = Invalid
--
dumps core on SIGQUIT
https://bugs.launchpad.net/bugs/62511
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
So you are saying fedora and debian are wrong in this regard?
And you're saying with `ulimit -c 0` the crashdump helper should still be
called,
even though _by default_ it's a python program.
Note the user (script) only has control over the ulimit setting in general,
not the system wide kernel
As noted, SIGQUIT as a crashdump signal is not a bug in itself. It's
also not a bug that SIGQUIT is handled by the crashdump helper (since
it's designed to be invoked any time a core dump would occur). If apport
wants to ignore this signal, that's great.
If the bug is that apport is too slow to
Confirming this is still an issue in the 2.6.24-1.1 Hardy kernel.
Thanks.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Importance: Undecided = Medium
Assignee: (unassigned) = Ubuntu Kernel Team (ubuntu-kernel-team)
** Tags removed: hardy-kernel-candidate
--
dumps core on SIGQUIT
https://bugs.launchpad.net/bugs/62511
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Tags added: hardy-kernel-candidate
--
dumps core on SIGQUIT
https://bugs.launchpad.net/bugs/62511
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
The system wouldn't be cluttered with core files surely
if the core_pattern is a pipe?
Also I confirmed 2.6.23.1-42.fc8 does not run the pipe when `ulimit -c
0`
I'm not sure if SIGQUIT should generate a core, but
it's probably mandated in some POSIX spec somewhere.
I certainly would be surprised
11 matches
Mail list logo
