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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.