Leistung und Virtualisierung

Perf erhält keinen Zugriff auf Performance-Events

Perf kann unter dem Sicherheitsrahmen kein Event aktivieren. Prüfe Paranoid-Regel, Capabilities und Containergrenzen vor umfassender Beobachtungsfreigabe.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Perf meldet fehlende Erlaubnis für ein angefordertes Event.
  • Ein Befehl funktioniert administrativ, scheitert aber als Benutzer oder im Container.

Betroffene Umgebung

Linux-perf_events-Zugriffskontrolle; perf muss installiert sein und der Beobachtungsbereich beeinflusst Rechte.

Erkennbare Meldungen (synthetische Beispiele)
No permission to enable cycles:u event.

Prüfe Event-Bereich und Sicherheitsregel; dies unterscheidet sich von einer fehlenden PMU.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • perf_event_paranoid oder fehlendes CAP_PERFMON kann den Beobachtungsbereich verbieten.
  • Container-Seccomp oder eine Sicherheitsregel kann perf_event_open unabhängig vom Host-Paranoid-Wert sperren.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Reine Regelabfrage; sie setzt keinen Wert.

sysctl kernel.perf_event_paranoid

Ergebnis einordnen: Der Wert hilft beim erlaubten Bereich, Distributionen können strenger sein. Ein freier Wert übersteuert weder Seccomp noch Sicherheitsrichtlinien.

Prüfschritt 2

Ersetze 1234 durch einen eigenen vorhandenen Prozess; liest fünf Sekunden Userspace-Zähler ohne perf-Datendatei.

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

Ergebnis einordnen: Rechtefehler zeigt Zugriffspolitik; not-supported dagegen Event-Verfügbarkeit. Nur Userspace begrenzt den Bereich, umgeht aber keine vollständige Syscall-Sperre.

Nächste Schritte nach Befund

Den erlaubten engen Beobachtungsbereich nutzen

Wenn eigene Userspace-Zähler erlaubt sind, erfasse nur diese statt systemweite oder Kernel-Events. Nutze Anwendungszeiten, wenn das benötigte Event in dieser Umgebung nicht erlaubt ist.

Vorsicht: Beobachtung kann Lastdetails offenlegen. Halte Ergebnisse im vorgesehenen Prüfbereich und erwarte nicht, dass weniger Events jede Grenze aufheben.

Wiederherstellung / Rücknahme: Beende die begrenzte Erfassung; dieser Weg benötigt keine dauerhafte Regeländerung.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Kontrollierten Performance-Zugriff erteilen

Wenn umfassende Analyse erforderlich und erlaubt ist, nutze ein gezielt verwaltetes CAP_PERFMON-Werkzeug oder eine begrenzte administrative Erfassung nach Hostregel. Prüfe im Container genaue Syscall- und Capability-Grenzen.

Vorsicht: CAP_PERFMON ist dafür gegenüber allgemeinem CAP_SYS_ADMIN vorgesehen. Senke die Paranoid-Regel nicht routinemäßig global.

Wiederherstellung / Rücknahme: Entziehe vorübergehende Capability oder Analysefreigabe und stelle notierte Host- oder Containerregeln zurück.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.