Take a Ftrace Snapshot with trace-cmd snapshot

trace-cmd snapshot freezes a copy of the current Ftrace buffer while the live trace keeps running underneath it. That means you can grab the moment something interesting happened without stopping the workload that caused it. Allow about 15 minutes for a first test, plus time to arrange a suitable trace workload.

This guide describes the installed trace-cmd 3.2.0 command from package 3.2-1ubuntu2. Snapshot support depends on the kernel and on tracing permissions, so the first job is checking those rather than assuming the feature is there.

1. Check the command and kernel support

Run the version and syntax checks as your normal user. They do not change tracing state:

$ trace-cmd --version
trace-cmd version 3.2.0 (not-a-git-repo)
$ trace-cmd snapshot --help
usage:
 trace-cmd snapshot [-s][-r][-f][-B buf][-c cpu]
          -s take a snapshot of the trace buffer
          -r reset current snapshot
          -f free the snapshot buffer
            without the above three options, display snapshot

The exact version suffix and help formatting can differ. The useful checkpoint is that the command lists -s, -r, -f, -c and -B. The manual page says the feature is only available when the kernel supports it.

Ask the command to display the current snapshot:

$ trace-cmd snapshot
trace-cmd: Permission denied
  Snapshot feature is not supported by this kernel
$ printf 'exit status: %s\n' "$?"
exit status: 13

That is the result on the machine used for this guide. Your output may show a snapshot instead. Do not treat a permission error as proof that sudo will fix it: the installed command can report an unsupported kernel separately from an access problem.

2. Start a small live trace

Once support is confirmed, create a short, controlled workload. Starting tracing changes kernel tracing state and normally needs elevated privileges. This example enables the function tracer:

$ sudo trace-cmd start -p function
$ sudo trace-cmd stat

The status output is host-specific. It should show tracing running and the function tracer selected. Keep the workload narrow on a busy production host: the function tracer can generate a large volume of events and affect performance.

$ sudo trace-cmd stop
$ sudo trace-cmd reset

stop halts recording; reset clears the tracing configuration and buffers. Treat reset as destructive to any trace data you have not saved.

3. Take the snapshot

Generate a little activity in another terminal, or run a deliberately small command in the shell where tracing is active:

$ /usr/bin/true

Now take the snapshot. This changes kernel tracing state, so use sudo when your setup requires it:

$ sudo trace-cmd snapshot -s
$ printf 'exit status: %s\n' "$?"
exit status: 0

A successful -s freezes a copy of the current buffer. It does not stop the live trace: events can keep arriving in the active buffer while the snapshot sits there waiting for you.

4. Read the frozen copy

Run the command without -s, -r or -f to display the snapshot:

$ sudo trace-cmd snapshot
          <... trace lines from the snapshot ...>

The output is trace data, not a stable report format. Look for events from the workload you created and compare timestamps or process names with what you expected. An empty or unexpectedly old result is a reason to check the selected tracer, workload timing and buffer instance before drawing any conclusions.

Take a second snapshot to replace the first one, then display it again:

$ sudo trace-cmd snapshot -s
$ sudo trace-cmd snapshot

The second -s updates the snapshot with the current active buffer. It does not append a second frozen report onto the first, so save any output you need before replacing it.

5. Clear or free the snapshot

Use -r to discard the current snapshot contents but keep the facility available:

$ sudo trace-cmd snapshot -r
$ sudo trace-cmd snapshot

The display after -r should no longer contain the data you cleared. This is destructive for that snapshot: it does not recover output you already discarded.

Use -f when you are finished and want to release the kernel memory allocated for the snapshot:

$ sudo trace-cmd snapshot -f

The next -s allocates the snapshot buffer again if it is no longer allocated. A safe cleanup sequence is therefore -f, followed by stopping and resetting the trace once the wider tracing session is finished:

$ sudo trace-cmd snapshot -f
$ sudo trace-cmd stop
$ sudo trace-cmd reset

If you need to preserve the active trace for another tool before cleanup, extract or save it first using the workflow that owns your tracing session. Do not reset merely to make a command return to an empty state.

6. Use a CPU or buffer instance deliberately

-c CPU operates on a per-CPU snapshot, although the manual warns that kernel support is not universal. Replace CPU_NUMBER with an actual CPU identifier from your host:

$ sudo trace-cmd snapshot -c CPU_NUMBER
$ sudo trace-cmd snapshot -c CPU_NUMBER -s
$ sudo trace-cmd snapshot -c CPU_NUMBER -r

Do not use a made-up CPU number. A per-CPU test that silently targets the wrong buffer sends you looking in the wrong place entirely.

If you created a tracing buffer instance, pass its name with -B to operate on that instance's snapshot:

$ sudo trace-cmd snapshot -B BUFFER_INSTANCE -s
$ sudo trace-cmd snapshot -B BUFFER_INSTANCE

Keep BUFFER_INSTANCE as the exact instance name, including its case. Omitting -B operates on the default tracing buffer, not automatically on every instance.

7. Diagnose the common failures

• Unsupported kernel. The command cannot provide a snapshot on that kernel. Check the message and kernel tracing configuration; do not loop on sudo hoping it changes the answer.
• Permission denied. Retry only after confirming that elevated access is appropriate for this host. Snapshot operations expose trace data, which can include process names, paths and other sensitive operational details.
• Unexpectedly empty data. Confirm that tracing is running, the chosen tracer is producing events, and you are reading the same CPU or buffer instance that you captured.
• Lost evidence. -s replaces the previous snapshot, -r clears it, and -f releases its storage. If the data matters, record or export it before any of those three.