Systemd - partie 2 | Yet another tech blog

Gustave Caillebotte - Périssoires sur l’Yerres (1877), huile sur toile, 103 × 155 cm, Milwaukee (USA), Milwaukee Art Museum.

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.

Les Managers#

La gestion des Units#

Arborescence et précédence#

Fragment Configuration#

Les Units#

Job et Transaction#

Conclusion#