@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 m
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
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
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. T
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 m
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 s
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 ig
** 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
https://lists.ubuntu.c
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)
Stat
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
** 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
https://lists.ubuntu.com
11 matches
Mail list logo
