---
name: "execsnoop-perf"
section: "8"
platform: "linux"
package: "perf-tools-unstable"
version: "1.0.1~20200130+git49b8cdf-1"
release: "Debian 13 (Trixie)"
platforms: ["linux"]
url: "https://new.carta.tech/execsnoop-perf"
---

# execsnoop-perf(8)

trace process exec() with arguments. Uses Linux ftrace.

## NAME

execsnoop - trace process exec() with arguments. Uses Linux ftrace.

## SYNOPSIS

**execsnoop** \[-hrt\] \[-a argc\] \[-d secs\] \[name\]

## DESCRIPTION

execsnoop traces process execution, showing PID, PPID, and argument details if possible.

This traces exec() from the fork()-\>exec() sequence, which means it won't catch new processes that only fork(). With the -r option, it will also catch processes that re-exec. It makes a best-effort attempt to retrieve the program arguments and PPID; if these are unavailable, 0 and "\[?\]" are printed respectively. There is also a limit to the number of arguments printed (by default, 8), which can be increased using -a.

This implementation is designed to work on older kernel versions, and without kernel debuginfo. It works by dynamic tracing an execve kernel function to read the arguments from the %si register. The stub\_execve() function is tried first, and then the do\_execve() function. The sched:sched\_process\_fork tracepoint, is used for the PPID. Tracing registers and kernel functions is an unstable technique, and this tool may not work for some kernels or platforms.

This program is a workaround that should be improved in the future when other kernel capabilities are made available. If you need a more reliable tool now, then consider other tracing alternatives (eg, SystemTap). This tool is really a proof of concept to see what ftrace can currently do.

Since this uses ftrace, only the root user can use this tool.

## REQUIREMENTS

FTRACE and KPROBE CONFIG, sched:sched\_process\_fork tracepoint, and either the stub\_execve() or do\_execve() kernel function. You may already have these on recent kernels. And awk.

## OPTIONS

- \-a argc

  Maximum number of arguments to show. The default is 8, and the maximum allowed is 16. If execsnoop thinks it has truncated the argument list, an ellipsis  "\[...\]" will be shown.

- \-d seconds

  Duration to trace, in seconds. This also uses in-kernel buffering.

- \-h

  Print usage message.

- \-r

  Include re-exec()s.

- \-t

  Include timestamps in units of seconds.

- name

  Only show processes that match this name. Partials and regular expressions are allowed, as this is filtered in user space by awk.

## EXAMPLES

- Trace all new processes and arguments (if possible):

  \# **execsnoop**

- Trace all new process names containing the text "http":

  \# **execsnoop http**

## FIELDS

- TIMEs

  Time of the exec(), in seconds.

- PID

  Process ID.

- PPID

  Parent process ID, if this was able to be read. If it wasn't, 0 is printed.

- ARGS

  Command line arguments, if these were able to be read. If they aren't able to be read, "\[?\]" is printed (which would be due to a limitation in this tools implementation, since this is workaround for older kernels; if you need reliable argument tracing, use a different tracer). They will be truncated to the argc limit, and an ellipsis "\[...\]" may be printed if execsnoop is aware of the truncation.

## OVERHEAD

This reads and processes exec() events in user space as they occur. Since the rate of exec() is expected to be low (\< 500/s), the overhead is expected to be small or negligible.

## SOURCE

This is from the perf-tools collection.

-

  https://github.com/brendangregg/perf-tools

Also look under the examples directory for a text file containing example usage, output, and commentary for this tool.

## OS

Linux

## STABILITY

Unstable - in development.

## AUTHOR

Brendan Gregg

## SEE ALSO

[top(1)](/top/1.md)