dumps core on SIGQUIT

[David Leadbeater]

If I terminate a command line application with SIGQUIT (e.g. with Ctrl+\), apport generates a crash report. I'm not sure it's very useful to be asking for reports of these, because a SIGQUIT is almost certainly user generated. (Also I seem to be getting a coredump in this case even when ulimit -c is set to 0..).

[Martin Pitt (pitti)]

apport is called whenever the kernel would create a core dump, and currently SIGQUIT is in the set of signals which trigger a core dump.

However, I agree that apport should just ignore these.

[Martin Pitt (pitti)]

I'm going to ignore SIGQUIT core dumps in apport, but it would be nice if the kernel would not call the crashdump helper and dump core for SIGQUIT in the first place, so that we do not waste the resources.

[Martin Pitt (pitti)]

 apport (0.23) edgy; urgency=low
 .
   * apport: Reset signal handler to SIG_IGN in the crash signal handler, to
     avoid an endless crash/handler loop (noticed during debugging LP#61708).
   * debian/apport.init: Do not let the script run with set -e, so that
     do_{start,stop} can deliver their return codes for proper evaluation,
     instead of immediately existing. Closes: LP#61796
   * test-apport: Check that SIGQUIT does not generate a report. (Check for
     bug #62511).
   * apport: Ignore SIGQUIT. Closes: LP#62511

[Pádraig Brady (p-draigbrady)]

wrt the kernel ignoring the crashdump helper for SIGQUIT,
it should be ignoring anyway as `ulimit -c 0` was set!
I.E. there seems to be an ubuntu specific bug here in that
the apport helper (or whatever is in /proc/sys/kernel/core_pattern)
is called even when one does `ulimit -c 0`

I tested Fedora 7 (2.6.21-1.3194.fc7), and this does not happen.
I tested Feisty (2.6.20-16-generic), and this does happen.

Does ubuntu have its own patches pertaining to /proc/sys/kernel/core_pattern
as I didn't notice any related fedora or upstream patches subsequent to 2.6.20?

One can reproduce by doing:

[root@f7]# echo "|/bin/true" > /proc/sys/kernel/core_pattern
[root@f7]# ulimit -c 0
[root@f7]# cat #hit Ctrl-\ now
Quit

[root@feisty]# echo "|/bin/true" > /proc/sys/kernel/core_pattern
[root@feisty]# ulimit -c 0
[root@feisty]# cat #hit Ctrl-\ now
Quit (core dumped)

Note ignoring the signal in apport does not suffice for me,
since I need the script in which Ctrl-\ is entered to respond immediately,
and starting the python interpreter and parsing the script
will be a significant delay (even though python 2.5 is much better in this regard).

cheers,
Pádraig.

[Pádraig Brady (p-draigbrady)]

On a debian sarge system with updated kernel to 2.6.20-1
I see the expected good behaviour also:

[root@2.6.20-1]# echo "|/bin/true" > /proc/sys/kernel/core_pattern
[root@2.6.20-1]# ulimit -c 0
[root@2.6.20-1]# cat #hit Ctrl-\ now
Quit

[Leann Ogasawara (leannogasawara)]

Hi Padraig,

Can you confirm this is still an issue with the new 7.10 Gutsy Gibbon release (2.6.22-14 kernel). Thanks!

[Pádraig Brady (p-draigbrady)]

Yes still a problem on gutsy with standard kernel:
2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

[Leann Ogasawara (leannogasawara)]

I'm marking this as "Won't Fix" against linux-source-2.6.20 as it does not meet the criteria for a stable release update. You can learn more about the stable release update process at https://wiki.ubuntu.com/StableReleaseUpdates . However, we'll hopefully get this fixed in the actively developed kernel. Thanks!

[Leann Ogasawara (leannogasawara)]

I'm marking this as "Won't Fix" against linux-source-2.6.17. It's the same reason for why it was marked "Won't Fix" against linux-source-2.6.20. Thanks!

[Martin Pitt (pitti)]

Calling the program in /proc/sys/kernel/core_pattern when it is a pipe even on ulimit 0 is a design choice, not a bug. We do not want to enable ulimit -c gemerally just for getting apport reports, since that would clutter the system with core files. (This now made it into the upstream kernel, too.)

The actual bug is that the kernel wants to dump core on SIGQUIT, which does not seem justified to me. It is not a signal that indicates a program error.

[Pádraig Brady (p-draigbrady)]

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 if it didn't.

[Leann Ogasawara (leannogasawara)]

Confirming this is still an issue in the 2.6.24-1.1 Hardy kernel. Thanks.

[Ben Collins (ben-collins)]

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 ignore the signal (as the user is concerned about response time), then that's something that apport will have to be faster about, or the user will have to disable apport usage.

[Pádraig Brady (p-draigbrady)]

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 setting.

[Leann Ogasawara (leannogasawara)]

Flipping back to Invalid as noted by Ben.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Christophe Lohr (christophe-lohr)]

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. They may have a number of very good reasons for this.
Whatever the reasons, this behavior (core dump on SIGQUIT) is normalized since POSIX.1-1990 (see man signal(7)).
Users can expect Ubuntu to follow the standards.
If you believe that this standard is inadequate, you can discuss this point in IEEE working groups. In the meantime, you should be well aware that Apport violates POSIX standrads.

So, can I suggest you reconsider your choice (and let Apport generate core dump on SIGQUIT)?

Otherwise, may I suggest you to clearly document your choice to prevent users of this non-standard behavior?

In addition, it would be good to provide a means for users to configure the behavior of Apport with respect to their process (via an environment variable, a configuration file in their home directory, etc.)

Best regards
Christophe

[Martin Pitt (pitti)]

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.

[Martin Pitt (pitti)]

However, this bug is for something different, so if it doesn't write a core file properly, please file a new report.

[Graeme Hewson (ghewson)]

@Christophe Lohr (#17) - See bug 1153662 "Core file not created on SIGQUIT", for which a fix has been released.