killsnoop - trace kill() syscalls with process and signal details. Uses Linux
[-hst] [-d secs] [-p pid] [-n name]
This traces kill() syscalls, showing which process killed which pid and returns
the returncode (0 for success, -1 for error).
This implementation is designed to work on older kernel versions, and without
kernel debuginfo. It works by dynamic tracing of the return value of kill()
and associating it with the previous kill() syscall return. This approach is
kernel version specific, and may not work on your version. It is a workaround,
and proof of concept for ftrace, until more kernel tracing functionality is
Since this uses ftrace, only the root user can use this tool.
FTRACE and KPROBE CONFIG, syscalls:sys_enter_kill and syscalls:sys_exit_kill
kernel tracepoints (you may already have these on recent kernels) and awk.
- -d secs
- Set the duration of tracing, in seconds. Trace output will
be buffered and printed at the end. This also reduces overheads by
buffering in-kernel, instead of printing events as they occur.
The ftrace buffer has a fixed size per-CPU (see
/sys/kernel/debug/tracing/buffer_size_kb). If you think events are
missing, try increasing that size.
- Print usage message.
- -n name
- Only show processes matching this process name. Partial
strings and regular expressions are allowed. This is post-filtered using
- -p PID
- Only trace this process ID. This is filtered
- Use human readable signal names, instead of signal
- Include timestamps, in seconds.
- Trace all kill() syscalls with details:
- # killsnoop
- Trace kill() syscalls with readable signal names, and
- # killsnoop -st
- Track kill() syscalls for processes named
- # killsnoop -n httpd
- Time of open() completion, in units of seconds.
- Process name (if known) of the process that issued the
- Process ID that issued the signal.
- Target PID for the signal.
- Signal number sent to the target process, or name if -s is
- Return status: 0 for success, -1 for failure.
This reads and kill() syscalls as they occur. For high rates of kills (>
500/s), the overhead may begin to be measurable, however, the rate is unlikely
to get this high. And if it is: you should investigate why. Test yourself. You
can also use the -d mode to buffer output, reducing overheads.
This is from the perf-tools collection.
Also look under the examples directory for a text file containing example usage,
output, and commentary for this tool.
Unstable - in development.
tpoint(8), execsnoop(8), opensnoop(8)