Menu
The SIGKILL signal is used to cause immediate program termination. It cannot be handled or ignored, and is therefore always fatal. It is also not possible to block this signal. This signal is usually generated only by explicit request.
SIGKILL instructs the process to terminate immediately. It cannot be ignored or blocked. The process is killed, and if it is running threads, those are killed as well. If the SIGKILL signal fails to terminate a process and its threads, this indicates an operating system malfunction.
SIGKILL cannot be blocked or ignored ( SIGSTOP can't either). A process can become unresponsive to the signal if it is blocked "inside" a system call (waiting on I/O is one example - waiting on I/O on a failed NFS filesystem that is hard-mounted without the intr option for example).
Usually, a SIGKILL results in the operating system choosing to kill a process after receiving the shutdown or restart commands by the user. An end user can directly send a SIGKILL signal to an application (with appropriate privileges).
I'm working on a program which uses shared memory. Multiple instances of said program will either connect to an existing one or create it anew, and give it back to OS when there are no other processes or just detach it and terminate. I thought of using a simple counter to keep track of how many processes use it.
I'm using atexit() function to do the cleanup, however, afaik, upon receiving SIGKILL signal, processes won't do any cleanup, so if any of those processes don't terminate normally, I might never be able to clean the memory.
Is there a way to specify what to do even after a SIGKILL signal? I'm probably going to write some mechanism similar to a timer to check if processes are still alive, but I'd really like to avoid it if there is another way.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With