We are dealing with a vendor's product, which has a nasty tendency to crash (with a massive core-dump) on shut down (upon receiving a SIGTERM).

We don't want to disable core-dumping for it completely, because, when crashes happen during normal runtime, cores are useful. Can we disable the core-dumping by a process right before killing it?

Other than by writing our own core-handling program, that is...

  • If the app was started via a systemd unit, you could try setting KillSignal=SIGKILL or some other signal in the unit (default is SIGTERM). This would then be used to stop the process. Or try adding a clean ExecStop= mechanism.
    – meuh
    Commented Jul 28, 2021 at 16:51
  • Yes, and we already asked the vendor if such a mechanism exists. Still, I wonder, if I can tell Linux, that a particular process' core shouldn't be dumped. After the process was started already...
    – Mikhail T.
    Commented Jul 28, 2021 at 16:55

1 Answer 1


One way I found -- surprisingly portable across different Unixes -- is to make the directory, where the core would be dumped (usually the process' current working directory), unwritable. For example, in this test the sleep-process will not produce a core-dump even upon segmentation-fault signal:

sleep 50 &    # Launch sleep in the background
chmod u-w .   # Make the current directory unwritable for the owner
kill -11 $!   # Send the backgrounded sleep-process a SIGSEGV
chmod u+w .   # Restore the directory's permissions

This is good enough for our purposes -- when we're shutting the app down, we don't want new files written in the directory anyway (neither core-dumps, nor anything else) -- but it may not be suitable for all...

Wish something else -- even if Linux-specific -- existed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .