When using a -R (trigger) option for an event system, it fails with no such file or directory error. That is: # trace-cmd record -e sched -R stacktrace /sys/kernel/tracing/events/sched/trigger: No such file or directory trace-cmd: No such file or directory opening to '/sys/kernel/tracing/events/sched/trigger' That's because "systems" do not have a trigger file. What trace-cmd should do is to add that trigger to all the events within the system. That is, instead of trying to update "events/sched/trigger" it should write "stacktrace" into "events/sched/*/trigger" instead.
I think the user should explicitly specify that the config should be applied to the all events from the given system and we should handle this case, not only for triggers: # trace-cmd record -e sched:* -R stacktrace or just # trace-cmd record -e sched: -R stacktrace
As a user does not need to explicitly specify that a config should apply to all events in a system to enable them, it would not be consistent to require that for triggers or other activities. This was a feature I added to trace-cmd from the beginning, because it's something that trace-cmd could figure out on its own without help from the user (if something is just a system or an event). That is: trace-cmd start -e sched would enable all events in a system called "sched" or any single event called "sched". The "sched:" would mean, only match systems (not events). As people have placed trace-cmd in scripts, adding this requirement will break backward compatibility. I don't see why we should place that requirement for triggers. Especially, as I'm one of the users to do such a thing, and I would prefer not to have to specify adding a ":".
Submitted a fix https://patchwork.kernel.org/project/linux-trace-devel/list/?series=261477
Fixed by: 7f21e017511d ("trace-cmd: Fix check for trigger file in create_event()") 346b41d6080e ("trace-cmd: Fix double free error when triggers are configured on multiple events") 2119c1135ec1 ("trace-cmd: Fix setting triggers to all events from given system")