«Cd» dans / sys / kernel / debug / tracing provoque un changement d'autorisation

J'ai fait face à un problème vraiment étrange aujourd'hui, et je suis totalement impuissant à ce sujet.

Certains des serveurs que je gère sont surveillés avec Nagios. Récemment, j'ai vu une sonde d'utilisation de disque échouer avec cette erreur:

DISK CRITICAL - / sys / kernel / debug / tracing n'est pas accessible: autorisation refusée

Je voulais enquêter et mon premier essai a été de vérifier les autorisations de ce répertoire et de les comparer avec un autre serveur (qui fonctionne bien). Voici les commandes que j'ai exécutées sur le serveur de travail et vous verrez que dès que je suis cddans le répertoire, ses autorisations sont modifiées:

# Here we've got 555 for /sys/kernel/debug/tracing
root@vps690079:/home/admin# cd /sys/kernel/debug
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Jul 19 13:13 ../
…
dr-xr-xr-x  3 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x  6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x  2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r--  1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x  2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x  2 root root 0 Jul 19 13:13 zswap/

# I cd into the folder, and it (./) becomes 700!!
root@vps690079:/sys/kernel/debug# cd tracing/
root@vps690079:/sys/kernel/debug/tracing# ll
total 0
drwx------  8 root root 0 Jul 19 13:13 ./
drwx------ 30 root root 0 Jul 19 13:13 ../
-r--r--r--  1 root root 0 Jul 19 13:13 available_events
-r--r--r--  1 root root 0 Jul 19 13:13 available_filter_functions
-r--r--r--  1 root root 0 Jul 19 13:13 available_tracers
…

# Next commands are just a dumb test to double-check what I'm seeing
root@vps690079:/sys/kernel/debug/tracing# cd ..
root@vps690079:/sys/kernel/debug# ll
total 0
drwx------ 30 root root 0 Jul 19 13:13 ./
drwxr-xr-x 13 root root 0 Sep 27 10:57 ../
…
drwx------  8 root root 0 Jul 19 13:13 tracing/
drwxr-xr-x  6 root root 0 Jul 19 13:13 usb/
drwxr-xr-x  2 root root 0 Jul 19 13:13 virtio-ports/
-r--r--r--  1 root root 0 Jul 19 13:13 wakeup_sources
drwxr-xr-x  2 root root 0 Jul 19 13:13 x86/
drwxr-xr-x  2 root root 0 Jul 19 13:13 zswap/

Avez-vous une idée de ce qui pourrait provoquer ce comportement?
Remarque: l'utilisation de chmod pour rétablir les autorisations ne semble pas résoudre le problème.

/ sys

/sysest sysfsune vue entièrement virtuelle des structures du noyau en mémoire qui reflète la configuration actuelle du noyau du système et du matériel, et ne consomme aucun espace disque réel. Les nouveaux fichiers et répertoires ne peuvent pas y être écrits normalement.

L'application de la surveillance de l'espace disque ne produit pas d'informations utiles et représente un gaspillage d'efforts. Il peut contenir des points de montage pour d'autres systèmes de fichiers virtuels basés sur la RAM, y compris ...

/ sys / kernel / debug

/sys/kernel/debugest le point de montage standard pour debugfs, qui est un système de fichiers virtuel facultatif pour diverses fonctionnalités de débogage et de traçage du noyau.

Parce qu'il s'agit de fonctionnalités de débogage, il est censé être inutile pour une utilisation en production (bien que vous puissiez choisir d'utiliser certaines des fonctionnalités pour des statistiques système améliorées ou similaires).

Étant donné que l'utilisation des fonctionnalités offertes par debugfswill dans la plupart des cas nécessite d'être de roottoute façon, et que son objectif principal est d'être un moyen facile pour les développeurs du noyau de fournir des informations de débogage, cela peut être un peu "approximatif".

Lorsque le noyau a été chargé, la routine d'initialisation du sous-système de suivi du noyau enregistrée en /sys/kernel/debug/tracingtant que point d'accès debugfs pour lui-même, différant toute autre initialisation jusqu'à ce qu'il soit effectivement accédé pour la première fois (minimisant l'utilisation des ressources du sous-système de suivi au cas où il s'avérerait pas besoin). Lorsque vous êtes cdentré dans le répertoire, cette initialisation différée a été déclenchée et le sous-système de suivi s'est préparé pour l'utilisation. En effet, l'original /sys/kernel/debug/tracingétait initialement un mirage sans substance, et il n'est devenu "réel" que lorsque (et parce que) vous y avez accédé avec votre cdcommande.

debugfs n'utilise aucun espace disque réel: toutes les informations qu'il contient disparaîtront à l'arrêt du noyau.

/ sys / fs / cgroup

/sys/fs/cgroupest un tmpfssystème de fichiers de type RAM, utilisé pour regrouper divers processus en cours d'exécution dans des groupes de contrôle . Il n'utilise pas du tout d'espace disque réel. Mais si ce système de fichiers est presque plein pour une raison quelconque, cela pourrait être plus grave que de manquer d'espace disque: cela pourrait signifier que

a) vous manquez de RAM libre,

b) un processus appartenant à root écrit des ordures /sys/fs/cgroup, ou

c) quelque chose provoque la création d'un nombre vraiment absurde de groupes de contrôle, peut-être dans le style d'une "bombe à fourche" classique mais avec des systemdservices basés sur ou similaires.

Conclusion

Une sonde d'utilisation du disque aurait dû /sysexclure car rien sous /sysn'est stocké sur aucun disque que ce soit.

Si vous avez besoin de surveiller /sys/fs/cgroup, vous devez lui fournir une sonde dédiée qui fournira des alertes plus significatives qu'une sonde d'espace disque générique.