when a process is killed is this information recorded anywhere?

StackOverflow https://stackoverflow.com/questions/1853884

  •  13-09-2019
  •  | 
  •  

Question

Question:

  • When a process is killed, is this information recorded anywhere (i.e., in kernel), such as syslog (or can be configured to be recorded syslog.conf)
  • Is the information of the killer's PID, time and date when killed and reason

update - you have all giving me some insight, thank you very much|

Was it helpful?

Solution

If your Linux kernel is compiled with the process accounting (CONFIG_BSD_PROCESS_ACT) option enabled, you can start recording process accounting info using the accton(8) command and use sa(8) to access the recorded info. The recorded information includes the 32 bit exit code which includes the signal number.

(This stuff is not widely known / used these days, but I still remember it from the days of 4.x Bsd on VAXes ...)

OTHER TIPS

Amended: In short, the OS kernel does not care if the process is killed. That is dependant on whether the process logs anything. All the kernel cares about at this stage is reclaiming memory. But read on, on how to catch it and log it...

As per caf and Stephen C's mention on their comments...

  1. If you are running BSD accounting daemon module in the kernel, everything gets logged. Thanks to Stephen C for pointing this out! I did not realize that functionality as I have this switched off/disabled.
  2. In my hindsight, as per caf's comment - the two signals that cannot be caught are SIGKILL and SIGSTOP, and also the fact that I mentioned atexit, and I described in the code, that should have been exit(0);..ooops Thanks caf!

Original

The best way to catch the kill signal is you need to use a signal handler to handle a few signals , not just SIGKILL on its own will suffice, SIGABRT (abort), SIGQUIT (terminal program quit), SIGSTOP and SIGHUP (hangup). Those signals together is what would catch the command kill on the command line. The signal handler can then log the information stored in /var/log/messages (environment dependant or Linux distribution dependant). For further reference, see here.

Also, see here for an example of how to use a signal handler using the sigaction function.

Also it would be a good idea to adopt the usage of atexit function, then when the code exits at runtime, the runtime will execute the last function before returning back to the command line. Reference for atexit is here.

When the C function exit is used, and executed, the atexit function will execute the function pointer where applied as in the example below. - Thanks caf for this!

An example usage of atexit as shown:

#include <stdlib.h>

int main(int argc, char **argv){
   atexit(myexitfunc); /* Beginning, immediately right after declaration(s) */
    /* Rest of code */
   return 0;
   exit(0);
}

int myexitfunc(void){
   fprintf(stdout, "Goodbye cruel world...\n");
}

Hope this helps, Best regards, Tom.

I don't know of any logging of signals sent to processes, unless the OOM killer is doing it.

If you're writing your own program you can catch the kill signal and write to a logfile before actually dying. This doesn't work with kill -9 though, just the normal kill.

You can see some details over thisaway.

If you use sudo, it will be logged. Other than that, the killed process can log some information (unless it's being terminated with extreme prejudice). You could even hack the kernel to log signals.

As for recording the reason a process was killed, I've yet to see a psychic program.

Kernel hacking is not for the weak of heart, but hella fun. You'd need to patch the signal dispatch routines to log information using printk(9) when kill(3), sigsend(2) or the like is called. Read "The Linux Signals Handling Model" for more information on how signals are handled.

If the process is getting it via kill(2), then unless the process is already logging the only external trace would be a kernel mod. It's pretty simple; just do a printk(), it's like printf(). Find the output in dmesg.

If the process is getting it via /bin/kill, then it would be a relatively easy matter to install a wrapper executable that did logging. But this (signal delivery via /bin/kill) is unlikely because kill is also a bash built-in.

By the way, if a process is killed with a signal is announced by the kernel to the parent process via de wait(2) system call. The value returned by this call is the exit status of the child (the lower byte) and some signal related info in the upper byte in case this process has been killed. See wait(2) for more information.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top