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...
use prlimit to set the core file size limit to 0.
sleep 50 &
prlimit -c0 -p $!
kill -11 $!
note that prlimit -c 0 -p $! does not work.
reference: the sanitizer in llvm-project also uses setrlimit, Modify ulimit (open files) of a specific process.
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.
KillSignal=SIGKILLor some other signal in the unit (default is SIGTERM). This would then be used to stop the process. Or try adding a cleanExecStop=mechanism.