Pseudos systèmes de fichiers

Rappels sur les points de montage

Les systèmes Unix définissent le système de fichiers comme étant un arbre unique partant d'une racine[1] et où l'on peut placer au sein de son arborescence des points de montage. Ainsi, l'utilisateur définit généralement deux points de montage :

/dev/sda1 on / type ext4 (rw,relatime,data=ordered)
/dev/sda3 on /home type ext4 (rw,relatime,data=ordered)

Dans ce schéma, la racine correspond à la première partition du premier disque, et les fichiers des utilisateurs sont sur la troisième partition du premier disque.

Présentation des pseudos systèmes de fichiers

D'autres points de montage sont utilisés par le système : /dev, /proc, /tmp, ... Ces points de montage vont, la plupart du temps, être montés par le programme d'initialisation en utilisant des systèmes de fichiers virtuels, mis à disposition par le noyau.

Ces systèmes sont virtuels, car ils ne correspondent à aucune partition d'aucun disque : l'arborescence est créée de toute pièce par le noyau pour trier les informations mises à disposition, mais il n'est pas toujours possible d'y apporter des modifications.

Linux emploie de nombreux systèmes de fichiers virtuels :

/proc : contient, principalement, la liste des processus (top et ses dérivés se contentent de lire les fichiers de ce point de montage) ;
/proc/sys : configuration du noyau ;
/sys : contient des informations à propos du matériel (utilisées notamment pour peupler /dev) et des périphériques (taille des tampons, clignottement des DELs, ...) ;
/sys/firmware/efi/efivars : pour accéder et modifier les variables de l'UEFI ;
...

Tous ces systèmes de fichiers sont généralement exclusivement stockés en RAM. Pour rendre une modification persistante, il est nécessaire de modifier un fichier de configuration qui sera chargé par le programme d'initialisation. Par exemple, pour modifier les paramètres du noyau, on passe par le fichier /etc/sysctl.conf et du programme sysctl.

Exercices

`rev_kdb_leds.sh`

Explorons le pseudo système de fichiers /sys pour écrire un script qui va inverser l'état des diodes de notre clavier.

Si vous avez :

numlock On,
capslock Off,
scrolllock Off ;

Après avoir exécuté le script, nous devrions avoir :

numlock Off,
capslock On,
scrolllock On.

Voici un exemple d'utilisation :

42sh$ ./rev_kdb_leds.sh input20

`procinfo`

Explorons le pseudo système de fichiers /proc pour écrire un script qui va afficher des informations sur un processus donné :

42sh$ ./procinfo $$
PID: 4242
Path: /bin/bash
Command line: bash
Working directory: /home/nemunaire/virli/
Root: /
State: S (sleeping)
Threads: 1

CGroups
=======
12:pids:/
11:net_prio:/
10:perf_event:/
9:net_cls:/
8:freezer:/
7:devices:/
6:memory:/
5:blkio:/
4:cpuacct:/
3:cpu:/
2:cpuset:/
1:name=openrc:/

Namespaces
==========
cgroup:[4026531835]
ipc:[4026531839]
mnt:[4026531840]
net:[4026531969]
pid:[4026531836]
user:[4026531837]
uts:[4026531838]

Rendu

Questions

Sur le serveur antares, un serveur applicatif critique tourne aux côtés de sa base de données PostgreSQL. Le serveur applicatif étant connu pour produire un grand nombre de leak, il est relancé chaque nuit. Le serveur applicatif tourne en root car plus personne ne sait le paramétrer ; la base de données a été installé par le système de paquets de la distribution.

Il arrive quelque fois que le serveur de base de données soit tué par l'OOM-killer alors que le serveur applicatif utilise largement plus de mémoire à la fin de la journée.

Quel paramètre du processus pourrait-on modifier pour que ce soit le serveur applicatif qui aie plus de chance de se faire tuer par l'OOM-killer ?
Pourquoi est-ce le serveur de base de données qui est principalement tiré au sort pour être tué en cas de manque de mémoire plutôt que le serveur applicatif qui occupe pourtant bien plus de mémoire ?

[1]: Consultez https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard pour plus de détails sur l'arboresence.

4.1 KiB Raw Blame History