Capture a Ftrace Snapshot with trace-cmd Without Losing the Live Trace

You will use trace-cmd snapshot to copy the current Ftrace buffer into a kernel snapshot, inspect that frozen copy, and then clear or release it safely. The live trace can continue while the snapshot is held. 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 tracing permissions, so the first job is to check those rather than assuming that the command is available.

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 available only 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 instead show a snapshot. Do not treat a permission error as proof that sudo will fix the problem: the installed command can report an unsupported kernel separately from an access problem. If support is absent, stop here and use a kernel or tracing setup that provides the Ftrace snapshot feature.

2. Start a small live trace

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

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

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

Checkpoint: before taking a snapshot, record what you started and leave a recovery command ready. If you need to abandon the test, stop and reset tracing:

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

stop halts recording and reset clears the tracing configuration and buffers. Treat reset as destructive to the 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 operation changes kernel tracing state, so use sudo when your tracing setup requires it:

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

A successful -s operation freezes a copy of the current buffer. It does not stop the live trace. Events can continue to arrive in the active buffer while the snapshot remains available.

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 the activity you expected. An empty or unexpectedly old result is a reason to check the selected tracer, workload timing, and buffer instance before drawing 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 operation updates the snapshot with the current active buffer. It does not append a second frozen report to the first one. Save any output you need before replacing the snapshot.

5. Clear or free the snapshot

Use -r when you want to discard the current snapshot contents but keep the snapshot 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 the 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 first -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 when 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 appropriate to 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 can send you looking in the wrong place.

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.
• 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 operations.