Systemd

Systemd

Présentation

Systemd est le remplaçant de Sys V init pour la gestion des services et du démarrage sous linux. Il est utilisé par défaut sous Redhat/CentOS depuis la version 7. Il reprend le principe de fonctionnement de svcadm sous Solaris 10 et plus. Comme pour svcadm, les services se lancent tous en parallèle, mais ne démarrent vraiment que lorsque les services dont ils dépendent sont actifs. Par exemple, le service sshd se lance et vérifie que le réseau est démarré ; tant que le réseau n'est pas actif, il attend ; dès qu'il le voit, il démarre. Ca permet de paralleliser au maximum les services au démarrage, pour gagner un maximum de temps.

De même que svcadm, systemd ne gère plus les runlevels, mais introduit la notion de target (les milestones sous Solaris). Cela correspond à un certain niveau de service atteint.

Concernant la gestion des services, systemd corrige ce que je considère comme un problème sous Solaris. Quand on arrête un service sous Solaris 10 et plus, ce service est automatiquement désactivé au démarrage. Idem quand on le démarre. Alors que systemd fait la différence entre activer un service (faire en sorte qu'il se lance au démarrage du serveur) et le démarrer.

Fichiers de configuration

Les fichiers de configuration sont dans /lib/systemd/system/ ou /usr/lib/systemd/system/ selon les distributions. Les modifications personnelles se font dans /etc/systemd/system/.

Le fichier de configuration principal est /etc/sysctl.conf. Il se recharge avec la commande systemd-sysctl.

Les unités

Systemd est principalement utilisé pour gérer les services, mais en réalité systemd gère plusieurs types d'unités. Les services sont un des types d'unités.

Lister tous les types d'unités.

systemctl -t help

Lister toutes les unités existantes sur le système.

systemctl list-units

Explication des types d'unité (source https://lea-linux.org/documentations/Systemd) :

• service : pour un service système ;
• socket : pour une socket de communication entre processus (de tous types : UNIX, Internet, fichier etc.) ;
• busname : pour les logiciels de communication inter-processus (par exemple dbus) ;
• target : macro-unité qui permet de grouper plusieurs unités (exemple : multi-user.target pour définir une cible) ;
• path : pour l'activation d'un service basée sur la modification de fichiers ou de répertoires (typiquement pour les files d'attente lors de l'impression) ;
• mount : pour un système de fichiers (exemple : home.mount), tout en utilisant /etc/fstab ;
• automount : pour un système de fichiers monté à la demande ;
• swap : pour les partitions de swap ;
• device : pour un périphérique ;
• timer : pour l'activation basée sur une date ;
• slice : sert pour la gestion des cgroups, une fonctionnalité du noyau Linux pour limiter, compter et isoler l'utilisation des ressources ;
• scope : utilisé par systemd lui-même pour gérer des groupes de processus, typiquement, par session utilisateurs ;
• snapshot : unités utilisées pour sauvegarder l’état actuel des services et les restaurer ensuite, par exemple avant de passer en veille.

Gestion des services

Prennons l'exemple du démon sshd.

systemctl start sshd.service		=> démarre
systemctl stop sshd.service		=> arrête
systemctl enable sshd.service		=> active au démarrage
systemctl disable sshd.service		=> désactive au démarrage
systemctl is-active sshd.service	=> répond juste "active" ou "inactive"
systemctl is-enabled sshd.service	=> répond juste "enabled" ou "disabled"
systemctl status sshd.service		=> affiche le statut complet
systemctl reload sshd.service		=> reload
systemctl restart sshd.service		=> restart
systemctl show sshd.service		=> affiche les propriétés détaillées
systemctl kill [-s 9] sshd.service	=> envoie un kill au process. Par défaut un SIGTERM=15, mais on peut préciser la valeur avec l'option -s

systemctl is-failed sshd.service	=> affice si un service est failed
systemctl --failed --type=service	=> affiche tous les services failed

systemctl list-unit-files --type=service --all	=> liste tous les services et leur statut
systemctl list-units --type=service		=> liste tous les services loaded

On a également l'argument mask qui désactive le service, et empêche son lancement ou son activation tant qu'on n'a pas fait un unmask.

systemctl mask sshd
systemctl unmask sshd

Il existe encore d'autres options que vous pourrez trouver dans la page man.

Les targets / runlevels

Comme expliqué dans la présentation, les targets viennent en remplacement des runlevels. Ils sont semblables aux milestones Solaris. Sur un serveur, la target par défaut est multi-user.target. Sur un poste de travail c'est graphical.target.

Chaque target correspond à un certain état du système, correspondant à un certain nombre de services démarrés.

systemctl get-default				=> voir son runlevel courant
systemctl list-units --type=target --all	=> lister les runlevels loaded et actifs
systemctl list-units --type=target		=> lister les runlevels loaded
systemctl set-default graphical.target		=> définit le runlevel par défaut
systemctl isolate graphical.target		=> définit le runlevel courant

Arrêt du serveur

Systemd gère également l'arrêt et le reboot du serveur. En fait, les commandes habituelles, comme reboot vont lancer les targets correspondantes, par exemple reboot.target. Mais c'est transparent pour nous. A noter que halt arrête le système d'exploitation, mais n'arrête pas électriquement le serveur ; il faut utiliser halt -p, ou poweroff sans option.

Les commandes systemd sont :

systemctl reboot	=> reboot
systemctl poweroff	=> arrêt
systemctl suspend	=> mise en veille
systemctl hibernate	=> hibernation

Création de service

1/ créer un fichier /etc/systemd/system/mon_service.service Exemple :

[Unit]
Description=Description de mon service
After=syslog.target
ConditionPathExists=/opt/nagios/

[Service]
Type=forking
PIDFile=/var/run/nrpe.pid
ExecStart=-/opt/nagios/nrpe start
ExecStop=-/opt/nagios/nrpe stop
Restart=always

[Install]
WantedBy=multi-user.target default.target

Remarque : de nombreux tutos disent qu'on doit rendre ce script exécutable. C'est faux. Il suffit de comparer aux scripts déjà existants.

2/ Faire un reload de systemd

systemctl --system daemon-reload

C'est tout. Maintenant on peut utiliser les commandes start, stop, enable, status etc avec notre nouveau service.

Pour plus de détails sur les options existantes, je vous conseille cet article : https://doc.ubuntu-fr.org/creer_un_service_avec_systemd.

Journal

Systemd possède son système de log. Il se gère avec la commande journalctl. On peut ajouter des options bien pratiques pour limiter le résultat. Voici quelques exemples.

journalctl
journalctl -p err			=> n'affiche que les erreurs
journalctl -f				=> affiche en continu (comme tail -f)
journalctl -u sshd			=> uniquement les logs de sshd
journalctl -f -u sshd			=> mix des deux précédentes
journalctl --since "10 minutes ago"	=> les 10 dernières minutes
journalctl --since "2019-07-31 21:00:00" --until "2019-08-01 12:00:00"	=> affiche une période de temps définie
journalctl --since yesterday		=> depuis hier
journalctl _PID=666			=> uniquement le pid 666

Toutes ces options peuvent se cumuler.

On peut paramétrer journalctl (taille des fichiers, compression, etc) en éditant le fichier cat /etc/systemd/journald.conf.

Autres commandes

Il existe des commandes commançant par systemd-. En voici quelques-unes.

systemd-analyze			=> affiche le temps de démarrage global
systemd-analyze blame		=> affiche le temps de démarrage de chaque service

Liens

• https://www.linuxtricks.fr/wiki/systemd-les-commandes-essentielles
• https://doc.fedora-fr.org/wiki/Systemd
• https://doc.ubuntu-fr.org/systemd
• https://lea-linux.org/documentations/Systemd
• https://doc.ubuntu-fr.org/creer_un_service_avec_systemd