2016-10-03 10:27:18 +00:00
|
|
|
\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
|
2017-09-27 08:05:55 +00:00
|
|
|
unique partant d'une racine[1] et où l'on peut placer au sein de son arborescence
|
2016-10-03 10:27:18 +00:00
|
|
|
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
|
2016-10-06 01:58:52 +00:00
|
|
|
disque : l'arborescence est créée de toute pièce par le noyau pour trier les
|
2016-10-03 10:27:18 +00:00
|
|
|
informations mises à disposition, mais il n'est pas toujours possible d'y
|
|
|
|
apporter des modifications.
|
|
|
|
|
2016-10-06 01:58:52 +00:00
|
|
|
Linux emploie de nombreux systèmes de fichiers virtuels :
|
2016-10-03 10:27:18 +00:00
|
|
|
|
|
|
|
- `/proc` : contient, principalement, la liste des processus (`top` et ses
|
|
|
|
dérivés se contentent de lire les fichiers de ce point de montage) ;
|
2016-10-05 09:13:56 +00:00
|
|
|
- `/proc/sys` : configuration du noyau ;
|
2017-09-27 08:05:06 +00:00
|
|
|
- `/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, ...) ;
|
2016-10-03 10:27:18 +00:00
|
|
|
- `/sys/firmware/efi/efivars` : pour accéder et modifier les variables de
|
|
|
|
l'UEFI ;
|
|
|
|
- ...
|
|
|
|
|
2016-10-06 01:58:52 +00:00
|
|
|
Tous ces systèmes de fichiers sont généralement exclusivement stockés en
|
2016-10-03 10:27:18 +00:00
|
|
|
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`.
|
|
|
|
|
|
|
|
|
2016-10-06 01:58:52 +00:00
|
|
|
## Exercices
|
2016-10-03 10:27:18 +00:00
|
|
|
|
2016-10-05 20:49:08 +00:00
|
|
|
### `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`
|
|
|
|
|
2016-10-03 10:27:18 +00:00
|
|
|
Explorons le pseudo système de fichiers `/proc` pour écrire un script qui va
|
|
|
|
afficher des informations sur un processus donné :
|
|
|
|
|
|
|
|
```
|
2016-10-05 09:13:56 +00:00
|
|
|
42sh$ ./procinfo $$
|
2016-10-03 10:27:18 +00:00
|
|
|
PID: 4242
|
|
|
|
Path: /bin/bash
|
2016-10-05 20:49:08 +00:00
|
|
|
Command line: bash
|
2016-10-03 10:27:18 +00:00
|
|
|
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
|
|
|
|
==========
|
2016-10-05 20:49:08 +00:00
|
|
|
cgroup:[4026531835]
|
|
|
|
ipc:[4026531839]
|
|
|
|
mnt:[4026531840]
|
|
|
|
net:[4026531969]
|
|
|
|
pid:[4026531836]
|
|
|
|
user:[4026531837]
|
|
|
|
uts:[4026531838]
|
2016-10-03 10:27:18 +00:00
|
|
|
```
|
2016-10-05 20:49:08 +00:00
|
|
|
|
|
|
|
## Rendu
|
|
|
|
|
2016-10-06 01:58:52 +00:00
|
|
|
### 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
|
2017-09-27 08:05:06 +00:00
|
|
|
l'OOM-killer alors que le serveur applicatif utilise largement plus de mémoire
|
|
|
|
à la fin de la journée.
|
2016-10-06 01:58:52 +00:00
|
|
|
|
|
|
|
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 ?
|
2016-10-05 20:49:08 +00:00
|
|
|
|
2016-10-06 01:58:52 +00:00
|
|
|
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 ?
|
2017-09-27 08:05:55 +00:00
|
|
|
|
|
|
|
[1]: Consultez <https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard> pour plus de détails sur l'arboresence.
|