C’est une réelle aide pour s’assurer de la non-régression mais également pour accélérer le processus de développement.

Init

Donc d’abord pour commencer, nous allons créer un role vide et explorer la structure proposée par Molecule.

En explorant la commande init role on obtient le résultat suivant :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

molecule init role --help
Usage: molecule init role [OPTIONS] ROLE_NAME

  Initialize a new role for use with Molecule, namespace is required outside
  collections, like acme.myrole.

Options:
  --dependency-name [galaxy]      Name of dependency to initialize. (galaxy)
  -d, --driver-name [delegated|openstack|podman]
                                  Name of driver to initialize. (delegated)
  --lint-name [yamllint]          Name of lint to initialize. (yamllint)
  --provisioner-name [ansible]    Name of provisioner to initialize. (ansible)
  --verifier-name [ansible|testinfra]
                                  Name of verifier to initialize. (ansible)

Ok donc créons notre nouveau rôle :

1

bash# molecule init role my_company.my_new_role -d podman

Cela aura pour effet de créer un nouveau role dans ./my_new_role

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

cd my_new_role/ && tree
.
├── defaults
│   └── main.yml
├── files
├── handlers
│   └── main.yml
├── meta
│   └── main.yml
├── molecule
│   └── default
│       ├── converge.yml
│       ├── molecule.yml
│       └── verify.yml
├── README.md
├── tasks
│   └── main.yml
├── templates
├── tests
│   ├── inventory
│   └── test.yml
└── vars
    └── main.yml

Au-delà de la structure classique d’un rôle, nous allons surtout nous intéresser au répertoire molecule qui contient tous les éléments nécessaires aux tests.

Au premier niveau un répertoire default, il s’agit du scenario par défaut, celui qui sera exécuté si aucune option n’est spécifiée (-s <nom_du_scenario> ou le nom du scenario est celui du répertoire).

Ensuite à l’intérieur le plus important molecule.yml.

Molecule.yml

C’est le fichier qui est requis dans chaque scenario. Il va servir à décrire et configurer : le driver, le(s) plateforme(s), le provisioner, le linter et le verifier

Dans notre exemple il ressemble à cela :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

---
dependency:
  name: galaxy
driver:
  name: podman
platforms:
  - name: instance
    image: quay.io/centos/centos:stream8
    pre_build_image: true
provisioner:
  name: ansible
verifier:
  name: ansible

dependency (doc)

Molecule utilise Ansible galaxy comme gestionnaire de dépendances. Cet objet va permettre de configurer ansible-galaxy pour installer les rôles et collections requises.

driver (doc)

Ici on spécifie le nom du pilote à utiliser pour accéder aux instances des plateformes sur lesquelles les tests seront exécutés.

Il existe différents types de drivers : podman, openstack, vagrant, docker, azure… qui correspondent chacun à une technologie pour créer des instances de tests (vm ou container).

Le driver delegated est quant à lui un peu particulier, car à la différence des autres il n’est pas chargé de créer / détruire les instances de test.

On peut l’utiliser par exemple pour se connecter à une machine préexistante en renseignant seulement une clé ssh.

Les drivers ne sont pas présents par défaut, ils doivent être installés dans les librairies Python de la façon suivante (ici Docker) :

1

pip install 'molecule[docker]'

platforms (doc)

C’est dans ce dictionnaire que nous allons retrouver la configuration de nos instances. Ces configurations sont bien évidemment dépendantes du driver utilisé (bien qu’il puisse y avoir des similitudes).

Leurs noms doivent être uniques (ils serviront de hostname pour ansible), sans limitation de nombre. On peut définir pour chaque instance un nom de groupe (et des children) pour générer l´inventaire de notre test.

Cette partie de configuration n’est pas forcément toujours très très bien documentée. Pour voir l’ensemble des options de configuration, il est souvent plus simple de se référer directement au code du driver (ou dans la section ‘Common uses cases’). Par exemple pour Docker on peut trouver le détail ici

provisionner (doc)

Cet objet est là où est défini la configuration d’Ansible. Il va être chargé à l’aide de playbook classique ansible de réaliser les actions suivantes :

• create : création de l’ensemble des plateformes à l’aide du driver. Ce playbook n’est appelé qu’une fois durant la durée de vie des instances de test
• prepare : utilisé par le tester pour appliquer les prérequis. Ce playbook n’est appelé qu’une fois durant la durée de vie des instances de test
• converge : applique le role en cours de test sur les instances.
• idempotence : re-applique le role et vérifie qu’aucun changed n’ait été déclenché
• side_effect : utilisé pour des tests de haute disponibilité (pas activé par défaut)
• verify : réalise les assertions sur les instances de tests (activé uniquement sur verifier = ansible)
• cleanup (*) : utilisé pour nettoyer les ressources avant le destroy
• destroy (*) : utilisé pour supprimer les plateformes de test.

Les playbooks des actions sont définis par défaut à la racine du scenario sous la forme ./$action.yml.

Il est également possible de définir des playbooks spécifiques par driver de la façon suivante ./$driver/$action.yml.

Enfin certains playbooks sont automatiquement définis par le driver lui-même.

Par exemple le driver docker va utiliser les arguments du dictionnaire des plateformes pour générer des Dockerfile via une template jinja2 et lancer la création des containers via un playbook Ansible.

Il est bien évidemment possible de définir des playbooks comme bon nous semble pour réaliser les actions que l’on souhaite.

Enfin, c’est aussi dans cet objet provisioner que l’on va pouvoir configurer ansible : niveau de log, variables, liens… etc

verifier (doc)

Le verifier est chargé de valider le bon déroulement du rôle, en réalisant des assertions sur les plateformes de test.

Par défaut Ansible est utilisé, les tests s’écrivent comme n’importe quel playbook (via par exemple le module assert)

Historiquement testinfra était privilégié pour cette tâche, dorénavant Ansible l’a remplacé. À titre personnel, je trouve que la syntaxe Ansible n’est pas vraiment efficace pour réaliser ce genre de tâche tant c’est verbeux à écrire. J’imagine que l’homogénéité a primé sur l’efficacité, car testinfra lui doit être écrit en python.

Les scenarios

(je me demande s’il n’y a pas une confusion entre les termes : scénario répertoire où se trouve le fichier molecule.yml et les scénarios la liste des séquences des actions)

Pour la bonne compréhension de l’outil je remets ici la liste par défaut des actions réalisées par molecule :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

scenario:
  create_sequence:
    - dependency
    - create
    - prepare
  check_sequence:
    - dependency
    - cleanup
    - destroy
    - create
    - prepare
    - converge
    - check
    - destroy
  converge_sequence:
    - dependency
    - create
    - prepare
    - converge
  destroy_sequence:
    - dependency
    - cleanup
    - destroy
  test_sequence:
    - dependency
    - lint
    - cleanup
    - destroy
    - syntax
    - create
    - prepare
    - converge
    - idempotence
    - side_effect
    - verify
    - cleanup
    - destroy

Ces séquences peuvent être appelées par les commandes suivantes :

1

molecule [create|check|converge|destroy|test]

NB: il peut être utile en phase de développement de travailler uniquement avec le converge, ainsi les phases “couteuses” (create et prepare) ne sont appelées qu’une fois et on peut travailler plus rapidement sur notre propre environnement.

Conclusion

Voilà qui conclut cet article, Molecule est un outil indispensable à Ansible. Il souffre néanmoins de quelques lacunes : documentation pas toujours très claire, pas de doc sur les drivers, la configuration du provisioner n’est pas simple à configurer dans des cas un peu complexes, et comme je l’ai dit plus le verifier ansible ne me semble pas idéal.

Je ne suis pas rentré beaucoup dans les détails mais tout est évidemment hautement paramétrable.

Pour autant une fois le pas franchi et la configuration mise en place, c’est un réel plaisir à utiliser (merci le molecule login)

Cet article sera consacré à l’architecture de systemd.

Le cœur de systemd est basé sur quelques piliers : UDev et DBus qui permettent de mettre en place une approche évènementielle, les CGroup pour l’encapsulation des processus et le contrôle des ressources et plus récemment EBPF pour les métriques.

Il se base sur plusieurs principes forts que je vais tenter de détailler ci-dessous.

Retarder l’initialisation

L’un des objectifs initiaux du projet était d’améliorer le temps de démarrage des systèmes jugé à juste titre trop long.

Il faut garder à l’esprit qu’il a été pensé pour répondre à ces différents cas d’utilisation (serveur, station de travail, embarqué…). Si le temps de démarrage n’est (souvent) pas crucial pour un serveur, ce n’est absolument pas le cas pour une station de travail ou pour un mobile.

Pour arriver à cela plusieurs types d’unit sont chargés uniquement de l’activation des services lors de leur première utilisation. On peut citer les types : socket, path, automount …

Cela permet d’éviter de lancer un service trop tôt (bien souvent au démarrage) et ainsi optimiser le temps de d’initialisation.

Pour réaliser cela systemd utilise plusieurs méthodes d’activation :

Les Socket.

Le principe est assez simple et est largement inspiré de ce qui se faisait déjà sur inetd. Mais contrairement à ce dernier, de nombreux types de socket sont maintenant supportés : UNIX, INET, named pipes, netlink…

On peut résumer les étapes de la façon suivante :

• Des buffers sont alloués automatiquement au démarrage pour chaque service qui le demande.
• Lors d’un appel, ces buffers se remplissent jusqu’à une taille limite au-delà de laquelle l’écriture devient impossible. Dans ce cas le client se met alors en attente et l’appel devient bloquant (c’est ce qui se passe d’ailleurs lorsqu’il attend une réponse).
• Les descripteurs de fichiers sont scrutés et au premier message le service consommateur est démarré en parallèle.
• Enfin on lui transmet le(s) socket(s) en paramètres afin qu’il puisse les lire une fois initialisé. En cas d’échec de démarrage, rien n’est lu et le service peut être relancé sans pertes d’informations.

Néanmoins, attention le passage de sockets n’est pas un comportement “natif” sous Linux. Il faut donc que le service soit compatible avec systemd (c’est heureusement le cas de nombreux serveurs web entre autres).

Grâce à ce comportement, on peut non seulement activer un service au premier appel, mais également briser les chaines de dépendances entre services et paralléliser leur activation.

Par exemple dans le cas d’un service qui nécessite syslog : Il est possible de lancer les deux en parallèle, les messages syslog seront envoyés mis en attente dans le buffer avant d’être dépilé à l’initialisation complète de syslog.

UDev

UDev est un daemon qui permet d’exposer dans l’espace utilisateur les périphériques de façon dynamique. Il prend en charge le hot-plug mais aussi pour les périphériques classiques.

C’est un daemon qui écoute dans l’espace utilisateur les évènements publiés par le kernel via netlink (un socket entre le kernel et l’espace utilisateur).

Il fait ensuite la liaison entres les informations du sysfs et déclenche des règles spécifiques écrites par un administrateur.

Ce projet a acquis une telle importance qu’il fait maintenant partie à part entière de systemd.

Prenons un exemple concret de comment utiliser UDev avec systemd.

Tout d’abord nous pouvons écouter les évènements publiés par le kernel et UDev ainsi :

1

udevadm monitor

Ce qui donne ce résultat lors de l’activation de bluetooth sur mon portable

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[88503.920800] change   /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/bluetooth/hci0/rfkill0 (rfkill)
UDEV  [88503.926695] change   /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/bluetooth/hci0/rfkill0 (rfkill)
KERNEL[88521.147695] add      /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/bluetooth/hci0/hci0:256 (bluetooth)
UDEV  [88521.151331] add      /devices/pci0000:00/0000:00:14.0/usb1/1-10/1-10:1.0/bluetooth/hci0/hci0:256 (bluetooth)
KERNEL[88522.280203] add      /devices/virtual/input/input24 (input)
KERNEL[88522.280341] add      /devices/virtual/input/input24/event18 (input)
UDEV  [88522.282180] add      /devices/virtual/input/input24 (input)
UDEV  [88522.319399] add      /devices/virtual/input/input24/event18 (input)

La première partie concerne la mise en route du récepteur bluetooth, la seconde la connexion du casque audio.

On voit apparaître un nouveau device sous l’arborescence /devices/virtual/input/input24.

Ensuite on cherche à écrire une règle UDev qui va s’activer uniquement pour ce périphérique. Pour cela il nous faut donc chercher les attributs discriminants dans les événements UDev que l’on peut voir à l’aide de la commande (attention les chemins UDev sont toujours relatifs aux répertoires /sys ou /dev/):

1

udevadm info -a /sys/devices/virtual/input/input24

Je serais bien incapable d’expliquer la signification de tous les attributs, par contre je peux en reconnaître quelque uns comme le nom et son adresse (qui me semble assez unique) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  KERNEL=="input24"
  SUBSYSTEM=="input"
  DRIVER==""
  ....
  ATTR{inhibited}=="0"
  ATTR{name}=="LG-TONE-FP9 (AVRCP)"
  ATTR{phys}=="0c:dd:24:30:06:00"
  ATTR{power/async}=="disabled"
  ATTR{power/control}=="auto"
  ....

Ensuite avec ces informations on est en mesure d’écrire une règle appropriée pour sélectionner ce matériel de la façon suivante :

1

SUBSYSTEM=="input",  ATTR{name}=="LG-TONE-FP9 (AVRCP)", ATTR{phys}=="0c:dd:24:30:06:00", TAG+="systemd", ENV{SYSTEMD_ALIAS}+="/sys/devices/virtual/input/lg_tone_fp9" 

Les premiers éléments servent à sélectionner les attributs dans les événements UDev qui vont déclencher la règle : le nom du system, l’attribut nom et son adresse.

Puis la partie importante pour l’intégration avec systemd est TAG+="systemd. Ce tag permet de marquer le périphérique pour être interprété comme une unit “.device”.

C’est d’ailleurs la seule chose à faire pour faire fonctionner cette règle avec systemd.

J’ai ajouté l’attribut SYSTEMD_ALIAS= car le chemin du périphérique n’est pas prévisible (/sys/devices/virtual/input/input<X>).

Comme le nom de la unit est déterminé par son chemin il est plus simple qu’il soit toujours le même. Maintenant ce device va apparaître systématiquement sous le nom sys-devices-virtual-input-lg_tone_fp9.device.

On est donc en mesure d’écrire un service qui va s’activer lors de la présence de ce device.

1
2
3
4
5
6

[Unit]
Wants=sys-devices-virtual-input-lg_tone_fp9.device

[Service]
ExecStart=/bin/echo headphone connected
RemainAfterExit=true

Il existe également la possibilité d’activer un service directement à partir d’une règle UDev.

D-Bus

D-Bus est un nouvel framework d’IPC (inter-process communication) qui permet de communiquer de façon standardisée entre différents services. Il permet - entre autre - de faire :

• du RPC (Remote Procedure Call) en offrant une sérialisation standardisée.
• de sécuriser les communications via un mécanisme d’autorisation.
• de l’activation à la demande via un système de nommage.
• de la découverte de service
• …

Systemd est complètement intégré avec D-Bus (l’architecture des deux produits est par ailleurs assez similaire).

Il est ainsi possible d’interagir avec systemd uniquement via les API D-BUS.

Pour voir les services exposés par DBus il suffit de taper la commande :

1
2
3
4

~ busctl list --acquired
NAME                                 PID PROCESS         USER             CONNECTION UNIT                             SESSION DESCRIPTION
...
org.freedesktop.systemd1               1 systemd         root             :1.1       init.scope                       -       -

On peut également voir l’ensemble des propriétés d’un service

1

~ busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1

Puis pour lister les propriétés, méthodes d’un service (systemd ici) :

1

~ busctl introspect org.freedesktop.systemd1 /org/freedesktop/systemd1

Cela donne accès à l’ensemble des objets accessibles via D-BUS (c’est aussi un bon moyen pour connaître les valeurs des propriétés par défaut).

On peut également écrire un service activable lors de la présence d’un bus de la façon suivante :

1
2
3
4
5
6
7

Unit]
Description=Simple DBus service

[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service

Bref les possibilités sont impressionnantes, tellement l’intégration des deux systèmes est poussée.

Inotify

Inotify est un mécanisme qui permet d’observer les actions sur un système de fichiers.

Il permet de s’abonner à un répertoire ou fichier et de recevoir les types d’évènements suivants :

• IN_ACCESS : le fichier est accédé en lecture ;
• IN_MODIFY : le fichier est modifié ;
• IN_ATTRIB : les attributs du fichier sont modifiés ;
• IN_OPEN : le fichier est ouvert ;
• IN_DELETE : un fichier a été supprimé dans le répertoire surveillé ;
• IN_CREATE : un fichier a été créé dans le répertoire surveillé.
• …

En symétrie nous allons donc retrouver sous systemd les fonctions suivantes PathExists=, PathChanged=, PathModified=, DirectoryNotEmpty=

Attention - comme spécifié dans la documentation - inotify souffre de certaines limitations, il n’est par exemple pas possible de scruter les évènements produits par une machine distante sur une filesystem en réseau (type NFS).

Autofs

Autofs est un module du kernel qui permet de retarder le montage d’un FS. Pour cela il crée des mount-trap (des dentry avec un attribut particulier) qui au premier accès (au-delà du stat) va faire appel à un daemon - dans notre cas systemd - qui va effectuer le montage. Par la suite le filesystem pourra être utilisé comme un FS habituel.

Cela offre deux avantages :

• alors que l’initialisation classique attend le montage de tous les FS (qui dans le cas de FS en réseaux peut être assez long), ici nous n’avons plus à attendre cette étape.
• cela permet également de paralléliser les montages.

Paralléliser

On l’a vu plus haut - en plus du chargement à la demande - beaucoup de composants facilitent la parallélisation des actions et font ainsi gagner en efficacité.

De son côté systemd se base sur son modèle de dépendances et cherche à minimiser les points de synchronisations qui ralentissent le démarrage.

Pour cela il va construire un arbre de dépendances pour pouvoir lancer un maximum de services en parallèle en ayant à attendre uniquement ceux qui lui sont nécessaires.

Pour arriver à cela des ordonnancements - souvent implicites - sont mis en place suivant différents critères afin de garantir la bonne cohérence des actions (c’est d’ailleurs souvent la partie la plus complexe à mettre en œuvre à mon avis).

Pour illustrer mes propos voici le graphique de démarrage, pour atteindre la default.target :

À noter quelques points qui me semblent importants :

• Lorsque systemd active un nombre de unit - et si aucun ordre n’est spécifié - elles sont faites en parallèle.
• Par défaut les services s’exécutent après la sysinit.target (ou à la basic.target en mode user). Pour passer outre il faut ajouter la propriété DefaultDependencies=false.

Comme souvent des outils sont mis à disposition pour nous aider : On peut citer systemd-analyse plot (en SVG) ou systemd-analyse dot (au format DOT) qui permettent de générer des représentations graphiques de ce que nous venons d’aborder.

L’utilisation des cgroups

Contrairement à ce que l’on pourrait croire le cgroups ne sont pas utilisés (du moins au départ) dans systemd pour le contrôle de resources, mais pour le contrôle des processus.

Il s’avère en pratique compliqué de terminer correctement un service ayant un nombre de processus forkés important.

Pour tenter de comprendre le problème, revenons sur quelques notions UNIX :

Un processus est rattaché à une session. Par convention le SID il est égal au PID du premier membre de la session, le “session leader”. La session peut être un terminal, une connexion ssh… ou autre.

Dans une session on trouve un certain nombre de groupes de processus. Le PGID est égal au PID du premier membre du groupe le “process group leader” (vous voyez la logique). Au sein d’une session un seul groupe peut être au premier plan.

Un processus PID a (presque) toujours un parent et hérite de certains de ses attributs (UID, GID, SID, PGID…). Il est lui-même composé de plusieurs threads.

Si en théorie c’est simple, en pratique, c’est assez compliqué : liberté d’implémentation, différences entre les systèmes UNIX, manque de syscall… Tout cela a fait qu’il est difficile de suivre correctement l’ensemble des processus issus de différents forks.

Par exemple l’une des techniques couramment utilisées pour lancer un processus en arrière-plan (daemon) est la technique dite du “double-fork”. Elle consiste à effectuer les opérations suivantes :

• Un premier fork() pour créer un processus enfant de façon classique.
• Qui va ensuite appeler setsid(0) pour se détacher de la session courante.
• Pour enfin effectuer un nouveau fork() pour que ce changement soit pris en compte. Le processus nouvellement créé est ainsi rendu orphelin et ne peut plus interagir avec la session d’origine (et vice versa).

Du point de vue d’un init manager, le problème est qu’il n’a connaissance que du PID issu du retour du premier fork, et pas de celui issu du second et éventuellement des autres processus forkés.

Une parade consistait à stocker le résultat du second fork dans un fichier PID file pour pouvoir le retrouver. Cette méthode est tout à fait valide, mais souffre de limites en cas de nouveau fork et est de plus très dépendante de l’implémentation qui en est faite.

On peut me faire remarquer que systemd utilise aussi des pid file, oui mais :

• c’est surtout pour assurer la rétrocompatibilité avec les anciens scripts.
• ce n’est pas exactement utilisé pour la même fonction (principalement par le watchdog).

Pour pallier ce problème, systemd utilise les CGroup.

Présent depuis longtemps dans le kernel Linux les CGroups sont prévus pour régler ce type de problème. À la différence d’autres propriétés un processus ne peut pas s’échapper d’un CGroup (à moins de créer un nouveau sous CGroup qui reste néanmoins toujours le descendant du parent). Il est de plus assez aisé de recenser l’ensemble des processus d’un CGroup.

Systemd a donc décidé de lancer tous les services dans leurs propres CGroup, cela permet de résoudre une bonne fois pour toutes les problèmes d’échappement des processus.

Et encore une fois fournit un outil pour nous aider :

1

systemd-cgls

Nous avons vu dans le précédent article quelques différences entre SysV init et systemd, ainsi que le mécanisme d’initialisation de l’espace utilisateur par le kernel. Dans cet article, je vais aborder plus en détail le fonctionnement de systemd.

Les Managers

L’objet manager est central, il contient les valeurs par défaut des différentes propriétés du système et est responsable de la gestion des units qui lui sont attachées. C’est avec lui que les “utilisateurs” vont communiquer.

Il est chargé de propager les actions appelées job (par exemple : start, stop, reload…) vers les units et d’interagir avec les éléments tiers du système (watchdog, inotify, D-bus, cgroups…).

Il en existe sous 2 formes ayant chacune des portées différentes :

La première (celle par défaut) appelée “system” est unique par machine et est normalement lancée par le processus d’init avec les droits root.

On peut vérifier que systemd est bien l’init manager du système de la façon suivante :

1
2

# ls -ls /usr/sbin/init
/usr/sbin/init -> /lib/systemd/systemd

Ou plus simplement utiliser cette commande :

1

systemctl

La seconde est “user”, il est unique par utilisateur et hérite des mêmes droits que ce dernier. Ce type d’instance s’avère particulièrement utile pour limiter les droits des services qui lui sont associés (rootless).

Pour connaître l’état d’une instance utilisateur on peut utiliser la commande suivante :

1

systemctl --user

Bien spécifier l’argument --user devant toutes les commandes pour interagir avec l’instance de l’utilisateur.

La gestion des Units

On l’a vu les managers sont responsables de la gestion des units.

Une unit chargée par un manager elle est unique si son nom est unique (pour les templates, les alias, les fragments, le nom est résolu au runtime).

Les units files sont lues au premier “référencement” (par exemple lors de leur activation, ou bien via de liens de dépendances…), transformées en unit et mise en cache dans la mémoire du manager qui leur est associé.

Elles sont stockées à l’intérieur d’une HashMap sous la forme nom/valeur (d’où leur unicité).

Pour cette raison, il faut forcer le ramasse-miette (GC) ce qui a pour effet de sérialiser sur disque l’état des units actives, vider le cache du manager et recharger la configuration des units via leurs unit file (ce n’est pas néanmoins pas toujours nécessaire, mais ça évite des erreurs).

Pour forcer le ramasse miette on utilise la commande suivante :

1

systemctl daemon-reload

Arborescence et précédence

La définition des unit files répondent à une précédence très précise utilisée afin de faciliter l’administration du système et sa mise à jour.

Par ordre d’importance croissante (non exhaustif) en mode “–system” :

• /lib/systemd/system/* : installés par le gestionnaire de paquets (il est recommandé d’éviter de les modifier sous peine de pertes lors des mises à jour du paquet)
• /usr/local/lib/systemd/system/* : gérés par l’administrateur
• /run/systemd/system/* : générées au runtime
• /etc/systemd/system/* : gérés par l’administrateur

Ainsi une unit file définie dans le répertoire /etc/systemd/system/* sera prioritaire sur celle définie dans /lib/systemd/system/*

En mode “–user” la hiérarchie est un peu différente :

• /lib/systemd/user/* : installés par le gestionnaire de paquets (ne doivent pas être modifiés sous peine de pertes lors des mises à jour)
• /usr/local/lib/systemd/user/* : gérés par l’administrateur
• /run/systemd/user/* : générées au runtime
• /etc/systemd/user/* : gérés par l’administrateur
• ~/.config/systemd/user/* : géré par l’utilisateur

Ça peut paraître compliqué aux premiers abords, mais limite le périmètre des différents intervenants sur une machine (utilisateurs, administrateurs, packageurs…) pour qu’ils ne se marchent sur les pieds.

De plus des outils spécifiques sont fournis (on le verra plus loin) pour aider à la compréhension de ce mécanisme.

Fragment Configuration

Les fragments configuration sont des fichiers qui permettent de modifier les propriétés d’une ou d’un groupe de units sans avoir à la/les redéfinir entièrement. Ces fichiers répondent aux mêmes ordres de précédence que nous venons d’aborder plus haut.

Pour surcharger, il est possible de définir des fichiers .conf qui seront lus par ordre alphabétique dans les formats suivants :

• Par type de unit sous la forme <unit_type>.d/*.conf. Ainsi un fragment dans un répertoire service.d/*.conf s’appliquera à tous les *.service
• Une unit spécifique sous la forme <unit_name>.d/*.conf
• Ou grâce à une pseudo hiérarchie et l’utilisation du signe ‘-’ dans le nom des units. Ainsi un fragment de configuration dans le répertoire foo-.d/*.conf va surcharger les configurations des units foo-bar.service, foo-foo.service et foo-bar-foo.service…

Voyons maintenant comment appliquer cela et les outils fournis par systemd pour nous assister dans la mise en place.

Si l’on crée le fichier /etc/systemd/system/service1.service de la façon suivante :

1
2
3

[Service]
Type=oneshot
ExecStart=/bin/echo hello world

Puis le fragment de configuration dans le fichier suivant /etc/systemd/system/service1.service.d/00-override.conf :

1
2

[Service]
ExecStart=/bin/echo running this first

Puis le fichier suivant /etc/systemd/system/service.d/00-override.conf :

1
2

[Service]
ExecStart=/bin/echo top level exec pre start

On obtient en utilisant la commande systemctl cat le détail de la configuration de la unit ainsi que ses différents fragments :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

$ systemctl cat service1.service
# /etc/systemd/system/service1.service
[Service]
ExecPreStart=/bin/echo hello world

# /etc/systemd/system/service1.service.d/00-override.conf
[Service]
ExecPreStart=/bin/echo running this first

# /etc/systemd/system/service.d/00-override.conf
[Service]
ExecPreStart=/bin/echo top level exec pre start

Et produit le résultat suivant :

1
2
3

top level exec pre start
running this first
hello world

Il est intéressant de noter que les surcharges sont additives. Pour passer outre les précédentes définitions, il faut d’abord déclarer la propriété à vide avant de la surcharger avec la valeur attendue.

1
2
3

[Service]
ExecStart=
ExecStart=/bin/echo top level exec pre start

Les Units

Les units sont les éléments de bases de systemd. Il existe 11 types différents de unit. Ils correspondent chacun à un type d’actions particulières.

Le type d’une unit est déterminé par le suffix de son unit file :

• *.service : Qui permet de définir un groupe de processus. C’est l’objet qu’on est le plus souvent amené à utiliser.
• *.socket : Pour faire de l’activation de services par sockets (IPC, network, unix socket…).
• *.device : Pour prendre en compte l’activation par périphériques via udev (dont le hot-plug).
• *.mount : Pour gérer le montage de partitions.
• *.automount : Qui permet l’activation des units .mount automatique lors du premier accès.
• *.swap : Configuration d’un point de montage swap
• *.target : Sont des point de synchronisation d’un ensemble de units (comme les run-levels de SysVinit), mais également des points de déclenchements.
• *.path : Activation par observation de chemins
• *.timer : Déclencheur périodique (à la manière de cron)
• *.scope : Configuration d’un ensemble de processus externes
• *.slice : Qui permet de regrouper un ensemble de processus au sein d’un cgroup commun.

Une unit est décrite par une unit file qui est lue au premier référencement pour être transformée en unit.

L’objet units implémente les opérations de bases génériques, une spécialisation est faite via la structure UnitVtable qui va référencer les méthodes spécifiques à chaque type.

Voici un exemple non exhaustif des méthodes de UnitVtable :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

typedef struct UnitVTable {
        /* How much memory does an object of this unit type need */
        size_t object_size;

        /* The name of the configuration file section with the private settings of this unit */
        const char *private_section;

        /* Config file sections this unit type understands, separated
         * by NUL chars */
        const char *sections;

        /* This should reset all type-specific variables. This should
         * not allocate memory, and is called with zero-initialized
         * data. It should hence only initialize variables that need
         * to be set != 0. */
        void (*init)(Unit *u);

        /* This should free all type-specific variables. It should be
         * idempotent. */
        void (*done)(Unit *u);

        /* Actually load data from disk. This may fail, and should set
         * load_state to UNIT_LOADED, UNIT_MERGED or leave it at
         * UNIT_STUB if no configuration could be found. */
        int (*load)(Unit *u);

        void (*dump)(Unit *u, FILE *f, const char *prefix);

        int (*start)(Unit *u);
        int (*stop)(Unit *u);
        int (*reload)(Unit *u);

        int (*kill)(Unit *u, KillWho w, int signo, sd_bus_error *error);

        /* Boils down the more complex internal state of this unit to
         * a simpler one that the engine can understand */
        UnitActiveState (*active_state)(Unit *u);

        /* Return false when there is a reason to prevent this unit from being gc'ed
         * even though nothing references it and it isn't active in any way. */
        bool (*may_gc)(Unit *u);

        /* Return true when the unit is not controlled by the manager (e.g. extrinsic mounts). */
        bool (*is_extrinsic)(Unit *u);

        /* Returns the exit status to propagate in case of FailureAction=exit/SuccessAction=exit; usually returns the
         * exit code of the "main" process of the service or similar. */
        int (*exit_status)(Unit *u);
        .....
} UnitVTable;

On retrouve logiquement dans l’objet Unit l’ensemble des sous-types, qui permettra de propager les actions génériques vers leurs implementations.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

const UnitVTable * const unit_vtable[_UNIT_TYPE_MAX] = {
        [UNIT_SERVICE] = &service_vtable,
        [UNIT_SOCKET] = &socket_vtable,
        [UNIT_TARGET] = &target_vtable,
        [UNIT_DEVICE] = &device_vtable,
        [UNIT_MOUNT] = &mount_vtable,
        [UNIT_AUTOMOUNT] = &automount_vtable,
        [UNIT_SWAP] = &swap_vtable,
        [UNIT_TIMER] = &timer_vtable,
        [UNIT_PATH] = &path_vtable,
        [UNIT_SLICE] = &slice_vtable,
        [UNIT_SCOPE] = &scope_vtable,
};

Un unit a un cycle de vie, et donc un état. Les états de base sont les suivants :

• Active
• Reloading
• Inactive
• Failed
• Activating
• Deactivating
• Maintenance

Cette liste d’état peut être, elle aussi, enrichie pour répondre au cycle de vie spécifique d’un type d’unit.

Par exemple pour une unit de type service on trouve cette liste d’états qui font tous la correspondance avec les états de base.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

static const UnitActiveState state_translation_table[_SERVICE_STATE_MAX] = {
        [SERVICE_DEAD] = UNIT_INACTIVE,
        [SERVICE_CONDITION] = UNIT_ACTIVATING,
        [SERVICE_START_PRE] = UNIT_ACTIVATING,
        [SERVICE_START] = UNIT_ACTIVATING,
        [SERVICE_START_POST] = UNIT_ACTIVATING,
        [SERVICE_RUNNING] = UNIT_ACTIVE,
        [SERVICE_EXITED] = UNIT_ACTIVE,
        [SERVICE_RELOAD] = UNIT_RELOADING,
        [SERVICE_STOP] = UNIT_DEACTIVATING,
        [SERVICE_STOP_WATCHDOG] = UNIT_DEACTIVATING,
        [SERVICE_STOP_SIGTERM] = UNIT_DEACTIVATING,
        [SERVICE_STOP_SIGKILL] = UNIT_DEACTIVATING,
        [SERVICE_STOP_POST] = UNIT_DEACTIVATING,
        [SERVICE_FINAL_WATCHDOG] = UNIT_DEACTIVATING,
        [SERVICE_FINAL_SIGTERM] = UNIT_DEACTIVATING,
        [SERVICE_FINAL_SIGKILL] = UNIT_DEACTIVATING,
        [SERVICE_FAILED] = UNIT_FAILED,
        [SERVICE_AUTO_RESTART] = UNIT_ACTIVATING,
        [SERVICE_CLEANING] = UNIT_MAINTENANCE,
};

Job et Transaction

Tout changement d’état d’une unit se fait au travers d’un Job. Il existe plusieurs types de job :

• Start / Verify
• Stop
• Reload
• Restart
• Nop

On trouve également d’autres types de Job qui sont la combinaison des types précédents : par exemple “try-restart” se transformera à l’exécution en “start” ou “nop” si la unit n’est pas activée ou en cours de rechargement.

Prenons l’exemple de la unit file suivante :

1
2
3

[Unit]
Wants=multi-users.target
...

La propriété Wants= a pour effet de créer une dépendance entre cette unit et la target unit “multi-user.target”.

NB : La plupart des relations peuvent être notées dans un sens ou dans l’autre (Before=/ After=, Require=/RequiredBy=…) On pourrait donc réaliser cette même dépendance à l’aide de la propriété WantedBy= dans la target et cela aurait le même effet.

Cette dépendance va avoir pour effet de propager l’activation de la target “multi-user.target” aux unit ayant une relation de type Wants= avec elle.

Lors de cette activation une transaction qui va contenir le job d’activation de la target en elle-même plus autant de job que de dépendances.

Ainsi dans le cas d’une relation avec une unit de type Wants= la transaction pourra être mise en succès même si ce job est en échec. Ce qui n’aurait pas été le cas avec une relation plus “forte” (par exemple Require=/RequiredBy=).

En pratique ces relations sont spécifiées par une énumération de propriétés beaucoup plus fines les UnitDependencyAtom ou “atoms” (qui ne sont rien d’autre qu’un bitmask).

Ainsi la propriété Wants= est composée de la sorte :

1
2
3
4

[UNIT_WANTS] = UNIT_ATOM_PULL_IN_START_IGNORED |
               UNIT_ATOM_RETROACTIVE_START_FAIL |
               UNIT_ATOM_ADD_STOP_WHEN_UNNEEDED_QUEUE |
               UNIT_ATOM_ADD_DEFAULT_TARGET_DEPENDENCY_QUEUE,

Cela lui permet de réagir aux propriétés suivantes qui peuvent être utilisées par différents objets (transaction, units…). Sans rentrer dans les détails on retrouve l’attribut “UNIT_ATOM_PULL_IN_START_IGNORED” le comportement décrit plus haut.

Il implémente un mécanisme de transaction connu sous le nom de Job qui s’assure de la transition d’une unit d’un état A vers un état B (par exemple start / stop / restart…).

Conclusion

Vous l’avez peut-être remarqué, mais systemd est conçu comme un système orienté objet. On retrouve d’ailleurs beaucoup de principes de la POO (polymorphisme, sous-typage, redéfinition…) dans les différents points que j’ai abordés

Voilà ainsi va se conclure cet article. Dans le prochain, nous aborderons l’architecture de systemd.

Je vais m’attacher dans cette partie introductive à expliciter la séquence de boot sous Linux pour m’arrêter au lancement du processus d’init. Puis faire la distinction entre systemd et SysV init sans rentrer dans les détails d’implémentation, puis revenir rapidement sur le débat autour de l’adoption du systemd.

Les détails techniques et l’utilisation de systemd en lui-même feront les sujets d’articles suivants.

Historique

Systemd a été développé à l’initiative de Lennard Poettering (la première version date de 2010 selon Wikipedia) comme étant le remplaçant - entre autres - de l’historique SysV init.

Promu par Red Hat, il a fini par s’imposer comme un standard de l’industrie dans les distributions majeures Linux, malgré les critiques encore nombreuses.

Systemd est la contraction de system daemon.

Du boot à l’init

Avant de parler de l’init il me semble important d’expliquer les étapes précédentes pour bien comprendre le contexte et le rôle de ce processus.

Donc lors du démarrage, la séquence est la suivante :

Le bootloader va sélectionner et lancer l’image du kernel au format bzImage (pour boot executable image), elle est située sur la partition de boot généralement sous le nom vmlinux.**.

Cette image est compilée et généralement assez minimale, c’est-à-dire qu’elle contient peu d’éléments statiques dans le but d’occuper un minimum d’espace disque et de faciliter son chargement et sa distribution. Grâce à cela une même image peut être utilisée par exemple aussi bien sur un téléphone portable que sur un serveur dernière génération (pourvu qu’ils utilisent la même architecture).

Pour réaliser le démarrage, il faut pouvoir accéder aux fichiers de configuration qui peuvent se trouver sur différents types de support : disque, partition, réseau… Pour y accéder, il est donc nécessaire de charger les différents modules/drivers correspondants.

Pour ce faire, il existe principalement deux méthodes :

• Soit pré-compiler dans l’image du kernel l’ensemble des drivers requis (mais sacrifier les avantages vus plus haut).
• Soit passer par une image temporaire contenant ce qui est nécessaire au démarrage du système.

Parmi la multitude de tâches d’initialisations (vm, console, horloge…) que le kernel va réaliser, on va s’intéresser à quelques-unes en particulier.

Instanciation du rootfs.

Le rootfs est un filesystem un peu spécial, c’est la base de tous les futurs filesystems, il est stocké en mémoire et est présent dès les premières étapes du démarrage du kernel, ne peut être démonté bien qu’il soit rarement utilisé après la phase d’init.

Il existe sous deux types :

• RAMFS qui est un simple “page cache” en mémoire dont aucun élément ne peut être persisté.
• TMPFS qui à l’inverse de RAMFS permet de limiter l’espace utilisé en mémoire et l’écriture sur la SWAP.

Le choix de l’un ou l’autre se fait à la compilation du kernel.

La décompression de l’initrd

L’image temporaire du rootFS évoquée plus haut s’appelle l’initrd (initial ram disk) en hommage à l’ancien fonctionnement (< 2.6) qui émulait un périphérique disque. C’est une simple archive compressée d’un filesystem au format cpio (un gz “amélioré”). Elle a l’avantage d’être plus facilement manipulable que l’image kernel, car non compilée. Il n’est donc pas nécessaire d’avoir un gcc ou des headers installés pour la générer ou la modifier. Elle est d’ailleurs régulièrement mise à jour au cours de la vie du système (souvent par les package managers).

on peut facilement lister le contenu grâce à la commande lsinitramfs ou la mettre à jour via update-initramfs

Cette archive est aussi stockée dans la partition de boot et passée en paramètre au kernel via le paramètre initrd=, qui va l’extraire dans le rootFS.

Enfin - et c’est là que le processus d’init à proprement parler commence - le kernel va appeler l’exécutable /init (ou l’exécutable spécifié via rdinit=) sur le rootFS.

L’initrd a pour but d’inclure les différents drivers et de monter le root device spécifié par le paramètre root= dans le dossier /root. Ensuite, il va supprimer les autres fichiers du rootFS puis appeler la fonction pivot_root pour transformer le répertoire /root en / (à la manière d’un chroot). Bien souvent (c’est le cas de systemd) ce processus va ré-exécuter une autre phase d’init pour prendre en charge la suite de l’initialisation du système après le montage du root.

Le montage “/root”

En cas d’absence de l’initrd le kernel va appeler la méthode prepare_namespace (qui remplit le même contrat que l’exécutable /init) c’est-à-dire tenter de monter le périphérique spécifié par le paramètre root= dans le répertoire /root, puis faire basculer ce répertoire à la racine.

Enfin il va appeler l’un des processus d’init suivants (/sbin/init, /etc/init, /bin/init, /bin/sh)

main.c ‘kernel_init()’

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

if (ramdisk_execute_command) {
    ret = run_init_process(ramdisk_execute_command);
    if (!ret)
        return 0;
    pr_err("Failed to execute %s (error %d)\n",
           ramdisk_execute_command, ret);
}

/*
 * We try each of these until one succeeds.
 *
 * The Bourne shell can be used instead of init if we are
 * trying to recover a really broken machine.
 */
if (execute_command) {
    ret = run_init_process(execute_command);
    if (!ret)
        return 0;
    panic("Requested init %s failed (error %d).",
          execute_command, ret);
}
if (!try_to_run_init_process("/sbin/init") ||
    !try_to_run_init_process("/etc/init") ||
    !try_to_run_init_process("/bin/init") ||
    !try_to_run_init_process("/bin/sh"))
    return 0;

panic("No working init found.  Try passing init= option to kernel. "
      "See Linux Documentation/admin-guide/init.rst for guidance.");

L’init

Comme c’est le premier processus lancé par le kernel, il porte donc logiquement le numéro PID=1.

Ce processus est un peu différent des autres :

• Ne peut être tué.
• N’a pas de parent PPID=.
• Est l’ancêtre de tous les autres processus.
• Est chargé d’initialiser tout un nombre de ressources (disque, terminaux, réseau, interface graphique…).

Sous linux les processus sont tous issus de la methode fork() ou dérivés.

Tous les processus enfants héritent d’un certain nombre d’attributs de leur parent : user, session, cgroup, mémoire partagé…

L’init a donc un rôle primordial dans la vie du système.

SysV init

Pour bien comprendre ce que systemd apporte il faut le comparer à son prédécesseur SysV init (j’ai choisi initV uniquement parce que c’était le plus répandu et que je l’ai un peu utilisé).

SysV init est basé sur les run-levels qui sont au nombre de 5 (presque) :

• 0 - réservé - Arrêt (halt)
• 1 - Mode utilisateur unique avec les filesystems montés.
• 2..5 Mode multi-utilisateur, les significations varient suivant les distributions, mais correspondent à l’état opérationnel de la machine.
• 6 - réservé - Redémarrage

Il faut d’ailleurs comprendre le nom SysV init comme étant “système 5 init” qui correspond aux 5 run-level de l’état d’un système.

Lors de l’init le système va passer d’un run-level à l’autre jusqu’à arriver au default level (qui peut varier suivant les distributions…) qui correspond au mode nominal de fonctionnement (par exemple une interface graphique pour un desktop ou un terminal pour un serveur).

En cas d’erreur du level X le level X+1 n’est pas appelé et l’initialisation est marquée en échec.

Chacun des levels agit comme un point de synchronisation, c’est-à-dire qu’il va déclencher un nombre d’actions à une étape précise du démarrage du système.

Par exemple si un daemon “A” nécessite une interface réseau ou des filesystems locaux, il a tout intérêt à se déclencher à un run-level supérieur à 1.

Scripts SysV init

SysV init est basé sur un ensemble de scripts, qui doivent répondre à des conventions, certaines peuvent varier suivant les distributions Linux utilisées.

Prenons l’exemple très simple d’un script de lancement d’un daemon :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

#!/bin/sh #(1)
# 
# Demonstrate creating your own init scripts 
# chkconfig: 2345 91 64 (2) 
### BEGIN INIT INFO (3)
# Provides: Welcome 
# Required-Start: $local_fs $all 
# Required-Stop: 
# Default-Start: 2345 
# Default-Stop: 
# Short-Description: Display a welcome message 
# Description: Just display a message. Not much else. 
###END INIT INFO 

# Source function library. 
. /etc/rc.d/init.d/functions #(4)

lock_file=/var/lock/subsys/myservice

start()  { 
   touch "$lock_file" 
   echo "Starting service" 
   sleep 2
 } 

case "$1" in  #(5)
      start) 
       start
        ;; 

      stop)
       rm -f  "$lock_file" 
       echo "Service is shutting down"  
       sleep 2 
        ;; 

     status)
       if [[ -f "$lock_file" ]]; then
         echo "Service looks good"
       else
         echo "Service not started !!"
       fi
        ;; 

         *)
       echo $"Usage: $0 {start|stop|status}" 
       exit 5 
esac 
exit $? #(6)

Il est composé :

• (1) D’une déclaration de l’interpréteur (ici shell)
• Ensuite une série de commentaires qui n’en sont pas :
  • (2) chkconfig qui permet de définir les levels d’exécution et le niveau de priorité
  • (3) LSB Headers qui contient des informations sur ordonnancement du service qui peut être éventuellement utilisé
• (4) L’import des fonctions communes /etc/rc.d/init.d/functions
• (5) Un switch case en fonction des arguments ‘start’ / ‘stop’ / ‘status’
• (6) Un code de retour

PROS :

• Offre un nombre de fonctionnalités assez complètes : ckconfig, lsb-headers.
• Une grande flexibilité : c’est un script shell on fait ‘ce qu’on veut’.
• Un début de standardisation (avec les fonctions, lsb headers, checkconfig).

CONS :

• Très verbeux, répétitif et difficilement extensible.
• Repose uniquement sur des conventions (start, stop, status…).
• Compliqué à réaliser.
• Peut avoir des comportements différents selon le contexte d’appel du script.

D’un point de vue utilisateur, on remarque bien que ce n’est pas standardisé (avec ses avantages et ses inconvénients) et en pratique demande pas mal d’expertise en script pour réaliser des choses assez semblables (gérer les sorties standards, changer d’utilisateur, lancer un daemon, exécution unique…)

Là où SysV init se résume à séquencer l’exécution de scripts (en schématisant), systemd se base sur de la description de configuration.

Service unit systemd

Ces configurations sont écrites au format ini et sont appelées “unit file” ou “unit” (mais ce n’est pas exact, car ça désigne les objets manipulés par systemd et non les fichiers).

Il existe plusieurs types d’unit files qui répondent à différents cas d’utilisations (service, montage…), chacune est suffixée par son type.

L’équivalent systemd du script ci-dessus est une unit file de type “service” que l’on pourrait adapter de la sorte :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Unit]
Description=Service

[Service] 
Type=simple
ExecStart=/usr/bin/sleep 2
ExecPreStop=/usr/bin/sleep 2 

[Install]
Wants=multi-users.target

La première chose que l’on remarque est que le fichier systemd n’est pas un script, il n’a donc pas d’utilité en dehors du contexte de systemd.

Deuxième chose, les attributs de configuration sont normés, ils correspondent à une série de propriétés interprétées par le programme. Ce n’est plus nous qui réalisons les actions, c’est systemd qui le fait à notre place.

Le script de base est extrêmement simple, et n’a pas vraiment de sens (encore moins avec systemd) mais met bien en évidence toutes les choses qui sont incluses de base dans systemd, et la différence entre les deux approches.

L’avantage ici d’être dans un “framework” est qu’il prend nativement en charge toutes les tâches usuelles sans avoir à les redéfinir nous-mêmes.

• Un service est unique, pour un même nom (au sein d’une instance systemd). Nous n’avons donc pas besoin de lock de synchronisation (il est possible de le variabiliser via le templating).
• Les états start / status / stop / restart sont implicites et communs à tous les services. Il faut noter que le status a souvent une signification un peu différente des scripts initV qui réalisent souvent des tâches de vérification assez complexes. Sous systemd le status ne reporte généralement que l’état du PID déterminé comme principal.
• Là où l’on devait spécifier via les lsb-headers l’ordonnancement (after $local_fs) fait ici partie de la valeur par défaut (cf defaultdependencies) qui doit répondre à la majorité des cas d’utilisations des daemons de haut niveau.
• Enfin on retrouve un équivalent des run-level avec l’attribut Target=multi-users.target qui sert ici également de point de synchronisation lors du démarrage.

Le mal aimé

On a beaucoup reproché à systemd d’être envahissant, et de briser le principe “un programme doit faire UNE chose et la faire bien”.

Oui systemd est envahissant, mais principalement parce que c’est un init system, une des pièces principales des systèmes UNIX. Il est de ce fait chargé de réaliser une multitude d’actions très différentes (monter les fs, mettre en place les interfaces réseau…). Ce qui était “caché” sous des scripts est ici rendu apparent.

Les défenseurs rétorquent souvent que systemd est modulaire - ce qui est vrai - mais cela ne me semble pas être un argument valable, les composants peuvent faire partie de différents projets/modules (journald, networkd, nspawn…) ils font tous partie d’un ensemble cohérent et ont tous vocation à fonctionner ensemble.

À mon avis la principale résistance est que systemd a imposé ses standards (en termes de nomenclature, arborescence, packaging et autres) au sein des distributions.

J’y vois également la réaction à la professionnalisation inévitable de l’écosystème Linux, avec la disparition progressive de l’esprit pionnier qui perdure dans les communautés de passionnés organisées autour des distributions / projets OSS. (Il faut aussi bien avouer que la communauté Linux ADORE les dramas et trouver des occasions de s’écharper).

Systemd n’est certainement pas idéal, mais il est “constant”. Il a indéniablement apporté beaucoup de bénéfices : facilitation du packaging, une meilleure portabilité, une qualité accrue et plus homogène, une facilité d’accès aux fonctions avancées du kernel…

Bref, il ne s’agit pas de défendre systemd mais bien de mettre en avant les bénéfices qu’il apporte.

• virtual memory
• memory management
• TLB
• …

Le Framework Rx prend une importance croissante dans le développement d’applications mobiles. Il apporte une très grande flexibilité dans la gestion des appels asynchrones et permet de répondre facilement aux problèmes de synchronisation des événements (le fameux Callback Hell).

Néanmoins l’apprentissage peut être assez déroutant au départ si l’on ne comprend pas la philosophie sur laquelle est basée ce Framework. Une fois cette étape achevée, il devient très simple de répondre à des problématiques d’enchaînement d’événements complexes.

Pour démarrer d’un bon pied nous allons d’abord définir les principes fondamentaux.

Les concepts fondamentaux.

Rx est basé sur le pattern Observer en utilisant la terminologie Subscriber / Observer et Observable (un Subject en Rx recouvre une notion bien particulière).

Les Observables

Le reactive programming voit les événements comme des flux qui se propagent dans l’application.

Ces flux peuvent avoir des sources multiples : une interaction avec un utilisateur (focus, sélection …), un élément extérieur (ex: la réponse d’un serveur distant) ou interne (la fin d’un traitement) etc.

Ils peuvent avoir une durée de vie déterminée (ex : une requête Http) ou non (ex le signal de perte de réseau). De la même manière ces flux peuvent ainsi émettre un ou plusieurs événements à des intervalles différents.

En Rx un Observable sert à matérialiser ces flux, ils peuvent être écoutés, avoir leurs propres cycles de vie, être composés de différents flux…

Les Subcribers

Est la notion la plus simple à appréhender. Il s’abonne à un Observable et il reçoit ses émissions, ses signaux d’erreurs ou fin de traitement.

Les Operators

Les Operators servent à traiter et organiser les flux. Ils permettent de filtrer, combiner, transformer, parcourir, composer des flux…

De base une foultitude d’opérateurs sont fournis. Bien qu’on puisse en créer de nouveaux, en pratique les opérateurs par défaut sont généralement largement suffisants pour répondre à la majorité des situations.

Les Schedulers

Par défaut Rx n’est pas asynchrone, pour la simple et bonne raison que le framework réserve cette décision au développeur de l’application.

Les Schedulers servent à contrôler l’exécutions des traitements. Il est alors très simplement possible de décider sur quel Thread va s’exécuter un Observable et sur lequel le Subscriber va recevoir les réponses.

RxJava en pratique.

Commençons d’abord par un exemple très simple pour illustrer les concepts vus précédemment.

Hello World !

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

Subscription subscription = Observable.just(example.dummyValue())
    .observeOn(Schedulers.newThread())
    .subscribe(new Observer<Boolean>() {
        @Override
        public void onCompleted() {
            System.out.println("dummyValue has Completed");
        }

        @Override
        public void onError(Throwable e) {
            System.out.println("Error occured : " + getMessage());
        }

        @Override
        public void onNext(Boolean aBoolean) {
            System.out.println("dummyValue result : " + aBoolean);
        }
    });
}

public boolean dummyValue() {
    try {
        Thread.sleep(600);
        return true;
    } catch (InterruptedException e) {
        throw new IllegalStateException(e);
    }
}

1. Observable.just crée un nouvel Observable avec une seule valeur de retour.
2. .observeOn définit que l’Observable s’exécute sur un nouveau Thread.
3. .subscribe s’abonne à l’observable.
4. Retourne un objet Subscription.

Il existe plusieurs méthodes génériques pour créer un Observable soit à partir de valeurs fixes, d’une collection, d’un Future<?> ou Callback<?> ou opérateurs. Il est aussi relativement facile de créer des Observable particuliers si l’on respecte son cycle de vie.

Comme vu précédemment par défaut un Observable s’exécute sur le même Thread que celui qui l’a instancié. En spécifiant Schedulers.newThread() on force l’exécution du traitement sur un nouveau Thread. Rx est fourni avec plusieurs schedulers prédéfinis tel que io, computation, … On a aussi la possibilité d’en créer afin d’optimiser la gestion des instances de Thread.

L’interface Observer est, elle aussi, relativement simple et lisible. Elle est composée de trois méthodes :

• onNext: appelé à chaque objet émis par l’observable.
• onError: lorsqu’une erreur s’est produite lors du traitement.
• onComplete: lorsque que l’observable a terminé d’émettre des éléments (Par contrat onNext ou onError ne seront plus jamais appelés).

L’objet Subscription - comme son nom l’indique - est la marque de la souscription d’un Observer vers un Observable.

Dans le cas présent, l’Observable est exécuté immédiatement avec une durée de vie fixée à un élément.

On peut schématiser son cycle comme ceci :

o —> onNext(true) –> onComplete()

Au travers de cet exemple basique, il faut noter la gestion ultra simple des threads et des erreurs, qui est à mon avis le gros avantage de ce Framework.

Débuter avec les Operators

Prenons pour exemple un Observable assez simple pour comprendre leur fonctionnement.

1

Observable<String> obs = Observable.just("a", "b", "c", "d", "e");

On aura donc 5 appels à onNext(String s) avant la méthode onComplete()

Le Subscriber affichera le résultat de onNext dans la console.

1
2
3
4

@Override
public void onNext(String result) {
    System.out.println("Result : " + result);
}

Par défaut les résultats seront donc :

Result : a Result : b Result : c Result : d Result : e

Filter:

1
2
3
4
5
6

.filter(new Func1<String, Boolean>() {
    @Override
    public Boolean call(String s) {
        return "a".equals(s) || "d".equals(s);
    }
})

Retourne :

Result : a Result : d

Take:

.take(2) ou .limit(2)

Retourne les x premiers éléments :

Result : a Result : b

TakeLast:

.takeLast(2)

Retourne les x derniers éléments :

Result : d Result : e

Map:

1
2
3
4
5
6

.map(new Func1<String, String>() {
    @Override
    public String call(String s) {
        return "Hello " + s + " !!";
    }
})

Applique pour chaque élément une transformation (il est également possible de modifier le type de retour) :

Result : Hello a !! Result : Hello b !! Result : Hello c !! Result : Hello d !! Result : Hello e !!

Ces opérateurs sont bien évidemment combinables entre eux.

En conclusion

Voici une première approche des basiques du Framework. Nous verrons par la suite les avantages de son utilisation, mais aussi les problèmes spécifiques liés à son utilisation dans de prochains articles.