I've realised recently that the kill utility can send any signal I want, so when I need to SIGKILL a process (when it's hanging or something), I send a SIGSEGV instead for a bit of a laugh (kill -11 instead of kill -9.)
However, I don't know if this is bad practice. So, is kill -11 more dangerous than kill -9? If so, how?
The SIGSEGV signal is sent by the kernel to a process that has made an invalid virtual memory reference (segmentation fault).
One way sending a SIGSEGV could be more "dangerous" is if you kill a process from a filesystem that is low on space. The default action when a process receives a SIGSEGV is to dump core to a file then terminate. The core file could be quite large, depending on the process, and could fill up the filesystem.
As @Janka has already mentioned, you can write code to tell your program how you want it to handle a SIGSEGV signal. You can't trap a SIGKILL or a SIGSTOP. I would suggest using a SIGKILL or a SIGSTOP when you only want to terminate a process. Using a SIGSEGV usually won't have bad repercussions, but it's possible the process you want to terminate could handle a SIGSEGV in a way you don't expect.
SIGSEGV can be trapped by the receiving program and then, may do anything the program wants.
SIGKILL and SIGSTOP are the only signals a program cannot trap or ignore.
