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


10

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.


1
Lorsque vous fournissez des échantillons d'entrée de terminal, pensez à remplacer les alias non standard, par exemple llpar les commandes qu'ils représentent.
Roman Odaisky

2
@RomanOdaisky C'est un alias par défaut dans Ubuntu, ne savait peut-être pas que ce n'était pas le cas par défaut
GammaGames

En plus de ce que @tecloM a dit, cela ressemble à un bogue du noyau pour votre version du noyau. Sur 4.19.0-4, le comportement est normal.
V13

Réponses:


20

/ 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.


1
Merci pour cette réponse avec autant de détails que nécessaire! Je vais exclure /sysde ma plage de surveillance.
zessx

1
@zessx: Exclure également /procet probablement /dev(car même s'il n'est pas 100% RAM, il contient d'une part un certain nombre de fichiers et de répertoires qui sont "bizarres" de diverses manières et, d'autre part, si vous consommer une tonne d'espace disque /dev, votre configuration est horriblement cassée et vous devez allumer tout le gâchis en feu).
Kevin

" /sysest sysfs, un système de fichiers virtuel entièrement basé sur la RAM" - je suis à peu près sûr que le contenu de sysfsest 100% synthétisé à partir de structures de données dans le noyau et ne vit pas dans la RAM quelque part. En fait, je dirais que "système de fichiers virtuel basé sur la RAM" est un oxymore: soit il est basé sur la RAM, c'est-à-dire qu'il a un magasin de sauvegarde (même s'il s'agit d'un magasin de sauvegarde très non traditionnel pour un système de fichiers), alors c'est pas virtuel, ou il est virtuel, alors il n'a pas de sauvegarde.
Jörg W Mittag

1
@ JörgWMittag Notez que j'ai très soigneusement évité de dire que sysfsc'est un RAMdisk. Où vivraient les structures de données dans le noyau, sinon en RAM, de toute façon? Je suis d'accord que le mot "virtuel" est problématique ici, car vous savez peut-être qu'en plus de tous les pilotes de système de fichiers du noyau Linux se trouve la couche VFS (Virtual File System), qui utilise "virtuel" dans un autre sens encore, comme une abstraction uniforme pour tous les systèmes de fichiers possibles. Mais il est difficile de décrire de manière concise comment procet sysfssont différents des vrais systèmes de fichiers, car il ne s'agissait que d'informations de base pour que le point principal reste fidèle.
telcoM

1
@grawity J'ai un peu modifié le libellé, serait-ce mieux maintenant?
telcoM
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.