Messages in this thread | | | Subject | Re: [PATCH] coredump: Retry writes where appropriate | From | Paul Smith <> | Date | Mon, 01 Jun 2009 15:51:39 -0400 |
| |
On Mon, 2009-06-01 at 20:02 +0100, Alan Cox wrote: > > If a program seems to be unresponsive the user could ^C, without > > realizing that it was really dumping core. Now when they are asked to > > produce the core so the problem can be debugged, they can't do it. Or, > > and get their prompt back, which is probably why they are banging ^C. If > they didn't want their prompt back at that point they'd still be > wondering why nothing was occuring at the point it said (core dumped)
True. My concern is that non-interactive, non-user controlled processes seem to be getting thrown out with the bathwater here in the search for the ultimate ease-of-use for interactive users. SIGINT is not just a user signal.
If it's interactive, can't the user ^Z (SIGSTOP) the process being dumped, then kill -9 %1? Does SIGSTOP stop a process that's dumping core? If this works it's not as simple as ^C, but I find myself doing that all the time for processes which are catching SIGINT, as Oleg points out.
Saying that SIGSTOP stops a core dump, SIGCONT continues it, SIGKILL cancels it, and everything else is ignored would be just fine with me.
Yes, you need a shell with job control but... at some point we have to just say it is what it is! Core dumps are not just annoying time/disk space wasters, they have real value; a good core dump can save tens of thousands of dollars or more in support and development costs. We need (a way for) them to be reliable, even if it costs some interactive ease-of-use.
Anyway, that's my opinion :-)
| |