Dennis HilkLinux Fix LabDE

Performance & Virtualization

Perf is denied access to performance events

Perf cannot enable an event under the current security scope. Check paranoid policy, capabilities and container restrictions before enabling broad monitoring.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Perf reports no permission to enable a requested event.
  • A command works as an authorized administrator but fails in a user or container context.

Relevant environment

Linux perf_events access control; perf must already be installed and event scope affects permissions.

Recognizable messages (synthetic examples)
No permission to enable cycles:u event.

Review event scope and security policy; this is different from an unavailable PMU.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • perf_event_paranoid or a missing CAP_PERFMON permission may forbid the requested observation scope.
  • Container seccomp or a security policy may block perf_event_open independently of the host's paranoid value.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read-only policy query; it does not set a value.

sysctl kernel.perf_event_paranoid

Interpret the result: The value helps explain allowed scope, but distributions may add stronger restrictions. A permissive value does not override seccomp or mandatory policy.

Check 2

Replace 1234 with your own existing process; reads user-space counters for five seconds and writes no perf data file.

perf stat -e cycles:u -p 1234 --timeout 5000

Interpret the result: Permission failure indicates access policy; not-supported indicates event availability instead. A user-space-only event narrows scope but cannot bypass an outright syscall denial.

Evidence-guided next steps

Use the narrow permitted observation scope

If policy permits own-process user-space counters, collect only those rather than system-wide or kernel events. Use application timings when the needed event is not allowed in this environment.

Precautions: Monitoring can reveal workload details. Keep collected output within the intended review scope and do not assume fewer events remove every restriction.

Recovery / rollback: Stop the bounded collection; no persistent access policy changes are needed for this approach.

Did this solution help you?

Share this solution#

Grant controlled performance-monitoring access

If broader profiling is required and authorized, use a narrowly managed CAP_PERFMON-enabled tool or administrator-run bounded capture according to host policy. In a container, review the exact syscall and capability restriction rather than enabling all privileges.

Precautions: CAP_PERFMON is preferred over general CAP_SYS_ADMIN for this purpose. Avoid globally lowering paranoid policy as a routine shortcut.

Recovery / rollback: Revoke the temporary capability or profiling access and restore the recorded host or container policy.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.