Hi, I was trying out a newer version of trace-cmd [1] and seem to have found an issue: $ trace-cmd trace-cmd version 2.6. $ trace-cmd reset <no output, everything's fine $./trace-cmd trace-cmd version 2.9.dev (4018b22056d772094a1fd2accf8f44f096ac3737) $ ./trace-cmd reset trace-cmd: No such file or directory opening to '/sys/kernel/tracing/tracing_max_latency' Note that this kernel wasn't compiled with either IRQ or preemption off tracers: $ zcat /proc/config.gz | grep TRACER CONFIG_NOP_TRACER=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_GENERIC_TRACER=y CONFIG_FUNCTION_TRACER=y CONFIG_FUNCTION_GRAPH_TRACER=y # CONFIG_IRQSOFF_TRACER is not set # CONFIG_PREEMPT_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_HWLAT_TRACER is not set # CONFIG_TRACER_SNAPSHOT is not set # CONFIG_STACK_TRACER is not set So as hinted by 5d4a9dba2d7f ("tracing: only show tracing_max_latency when latency tracer configured"), the file won't be there. From a quick look at the code, trace-record.c::reset_max_latency() ends up calling write_file() which die()'s if it can't open the file. Perhaps files that are not guaranteed to be there could use a e.g. "try_write_instance_file()" which would first check for the presence of the file and return gracefully if it's not there, rather than die(). Cheers, Valentin [1]: https://github.com/ARM-software/lisa/pull/1144
Hi Valentin, Thank you for the testing and posting this bug. You are right, depending on the kernel config, some ftrace files are optional and this should not confuse trace-cmd. -- Tzvetomir (Ceco) Stoyanov VMware Open Source Technology Center
Proposed a fix: https://patchwork.kernel.org/patch/11198623/
Fixed by commit 113b0664003c ("trace-cmd: Check if ftrace file exists, before writing in it.")