virli/tutorial/3/pseudofs.md

\newpage

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 :

```shell
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.

1. 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 ?

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