Clear Ftrace Buffers Safely with trace-cmd

trace-cmd clear wipes the current kernel Ftrace ring-buffer contents, and once it's done there is no getting those records back. It can target the top-level buffer, named instance buffers, or every buffer at once. This guide covers checking what you are about to lose, then clearing the right scope deliberately.

This uses trace-cmd 3.2.0 from Ubuntu package version 3.2-1ubuntu2. Allow about ten minutes to clear and verify a buffer, longer if you first need to identify which tracing instance is producing the data. You need a shell, the installed trace-cmd package and access to the kernel tracing interface; some systems require elevated privileges for that.

Warning: Clearing a buffer removes trace evidence. If the data might matter for an incident, bug report or performance comparison, save or report it first. Don't run the examples below in a production troubleshooting session until you've decided losing the current records is acceptable.

1. Check the installed command

Start with read-only checks; these don't alter tracing:

$ trace-cmd --version
trace-cmd version 3.2.0 (not-a-git-repo)
$ trace-cmd clear --help
usage:
 trace-cmd clear [-B buf][-a]

clear is a subcommand of trace-cmd, not a separate executable. The manual describes two controls: -B buffer-name selects a buffer and can be repeated, while -a clears every existing buffer, including the top-level one.

Checkpoint: Make sure the version and help output belong to the host you actually intend to change:

$ command -v trace-cmd
/usr/bin/trace-cmd
$ dpkg-query -W -f='${Package} ${Version}\n' trace-cmd
trace-cmd 3.2-1ubuntu2

2. Inspect tracing before you clear it

Check whether tracing is active, and whether the records you are about to remove are ones someone actually needs:

$ trace-cmd stat

The exact output depends on your kernel and tracing setup, so read it rather than relying on a remembered example. If a recording, service or diagnostic script is currently writing events, clearing the buffer can remove the only copy of them. Stop and coordinate with that process first.

If you need to see the current records before wiping them, redirect the read-only display command to a file that won't overwrite anything valuable:

$ trace-cmd show > ftrace-before-clear.txt
$ test -s ftrace-before-clear.txt && echo "saved a non-empty snapshot"
saved a non-empty snapshot

That saves the text trace-cmd show displays; it is not a substitute for a proper trace.dat recording. Keep the file until you're sure clearing was the right call.

3. Clear the top-level buffer

When the target is the normal top-level Ftrace buffer:

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

A zero exit status means it worked. It doesn't print what it removed and doesn't create a backup. The shell prompt returning is not proof that another tracing process has stopped writing, a busy tracer can repopulate the buffer immediately.

Check the result with a read-only display:

$ trace-cmd show

On a quiet system this can show nothing at all. If records do appear, check first whether tracing is still active, they can also just be new events written after the clear finished.

4. Clear one named buffer

Kernel tracing can expose additional buffers. To clear only one, pass its exact name:

$ BUFFER_NAME='INSTANCE_NAME'
$ sudo trace-cmd clear -B "$BUFFER_NAME"
$ printf 'exit status: %s\n' "$?"
exit status: 0

Replace INSTANCE_NAME with the name your tracing setup actually uses. Don't guess it, and don't treat an empty shell variable as a valid target: check it before reaching for sudo:

$ test -n "$BUFFER_NAME" && printf 'clearing buffer: %s\n' "$BUFFER_NAME"
clearing buffer: INSTANCE_NAME

Tip: With -B, the manual says the top-level buffer is not cleared, a useful boundary when one instance has stale data but another buffer needs to stay intact. Repeat the option to target several named buffers at once:

$ sudo trace-cmd clear -B 'INSTANCE_A' -B 'INSTANCE_B'

There's no undo for either example. Recovery means getting another trace from the source, or restoring a previously saved recording.

5. Clear every buffer only when that's deliberate

-a clears every existing buffer, including the top-level one:

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

This is much broader than naming one buffer. Use it as a reset point only after saving anything needed and confirming no other operator or service depends on the current records. It doesn't mean "clear all the buffers I named", that's what repeated -B is for.

Recovery: If the command fails, keep the error text and check permissions and the kernel tracing state. Adding sudo can fix an access-denied error, but it can't make a misspelled buffer name valid or bring back data already cleared. Avoid repeatedly retrying while a live diagnostic is producing records, each successful retry can discard more evidence.

Done means