Admin/Systemd/Brief

Gérer les Services avec systemctl

Gestion basique

Systemd est un gestionnaire de service. C'est le tout premier processus (PID 1) a être lancé et aussi le seul a être lancé par le noyau. Il doit donc assurer toute l’initialisation du système, le lancement des différents services et des systèmes permettant la connexion des utilisateurs. De plus il doit gérer les processus orphelins afin qu'il ne deviennet pas des processus zombies.

Il permet de lancer les processus, de les arrêter, de les relancer, bref, d'en assurer un suivi.

C'est aussi un gestionnaire de session. Il permet l'utilisation du même matériel en passant d'une session (~loging) à une autre sans que cela pose de problème. Il permet encore de gérer les points de montage qu'ils soient automatiques ou non.

C'est le successeur du gestionnaire de service SysVinit (init System V) et peut aussi remplacer xinetd, cron, syslog. La consultation des logs se fait avec Journalctl. Il a comme avantages:

• Il démarre moins de choses
  Le démarrage d'un service est soumis à son utilité (ex le service de gestion du bluetooth ne deviend utile que lorsqu'un périphérique bluetooth s'enregistrera sur DBUS). Ce mode de fonctionnement ressemble à inted et xinetd.
• Il démarre les services en parrallèle (en respectant un arbre de dépendances).

Systemd dispose d'une notion d'unité (unit in english).

• service : les plus simples correspondent à des services. Peuvent être démarrés, coupés, redémarrés, reconfigurés (start/stop/restart/reload), comme on le fait habituellement avec les scripts dans /etc/init.d/ ;
• socket : correspond à une socket, que ce soit de type UNIX, de type Internet, de type fichier ; chaque socket a un service correspondant ;
• mount : un système de fichiers ; ces unités viennent en plus du fichier /etc/fstab qui est utilisé directement ;
• swap : pour les partitions d’échange ;
• automount : un système de fichiers monté à la demande ;
• target : une macro‐unité qui permet de grouper plusieurs unités, par exemple multi-user.target ou bluetooth.target ;
• snapshot : comme target, ce sont des unités qui peuvent être utilisées pour sauver l’état actuel des services et les restaurer par la suite, par exemple avant de passer en veille ;
• device : un périphérique dans le système Linux ; peut être une source de dépendance via udev ;
• timer : activations à la sauce cron, en fonction de la date ;
• path : sert pour l’activation basée sur la présence ou la création de fichiers ou répertoires.

Les services sont un type d'unité.

• Démarrage d'un service. C'est l'équivalent de <app>service myservice start</app>

  systemctl start myservice.service

• Arrêt d'un service. C'est l'équivalent de <app>service myservice stop</app>

  systemctl stop myservice.service

• Ajout d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice on</app>

  systemctl enable myservice.service

• Suppression d'un service au démarrage. C'est l'équivalent de <app>chkconfig myservice off</app>

  systemctl disable myservice.service

Actions Systemd
Il existe bien sûr d'autres actions possibles, tel que reload, status, etc...

Avantages

• Pour chaque service, il est possible de régler de nombreux paramètres : limites, répertoire racine (chroot), umask, priorité, paramètre « OOM killer » (out of memory), les classes et les priorités d’ordonnancement et d’entrées‐sorties, l’affinité processeur, l’utilisateur, les groupes, les répertoires accessibles et les modes d’accès, les capacités, le répertoire temporaire, le réglage des cgroups…
• Les flux stdout et stderr peuvent être redirigés vers le service de journalisation, vers « /dev/kmsg », vers un terminal ou vers un fichier.
• Intégration de SELinux, des « TCP wrappers », des modules d’authentification PAM.
• Chaque service a son propre cgroup.
• Chaque connexion via un terminal est aussi placée dans son propre cgroup, ce qui permet de fermer complètement une session et d’isoler un peu mieux les utilisateurs (processeur, mémoire).
• La syntaxe des fichiers de configuration suit celle bien connue des fichiers « .desktop ».
• Le système est compatible avec les anciens scripts SysVinit. Les informations LSB et chkconfig (de Red Hat) ainsi que celles de Debian et d’OpenSUSE sont utilisées lorsqu’elles sont disponibles. Sinon, l’ordre de démarrage dans « /etc/rc.d/ » est utilisé. systemd est également capable de lire le fichier PID pour retrouver un service. Ces données permettent d’émuler une configuration classique SysVinit, facilitant la transition.
• Le fichier « /etc/fstab » est également lu comme s’il s’agissait d’un fichier de configuration de systemd.
• Les fichiers natifs systemd masquent ces émulations, permettant de faire des paquets compatibles avec les deux systèmes, le nouveau masquant l’ancien si nécessaire.
• Il existe un système de modèles pour éviter de dupliquer une configuration (par exemple, pour les 6 getty des terminaux virtuels habituellement lancés).
• systemd fourni une couche de compatibilité avec « /dev/initctl » permettant d’utiliser les vieux binaires, tels que shutdown ou reboot. Les ordres sont transmis à systemd via D-Bus. Il prend en charge également kexec qui permet de relancer le noyau Linux.
• Il gère utmp et wtmp, les journaux système enregistrant les connexions.
• Chaque processus lancé est tracé par son heure de démarrage, de fin, son PID et son code de retour ; permettant d’analyser les anomalies.
• systemd est capable de se ré‐exécuter lui‐même, afin de faire une mise à jour, ou de passer d’un processus provenant d’un « RAM‐disque » d’amorçage (initrd) au système final. Tout l’état courant est migré d’un processus à l’autre.
• La mise en place des systèmes de fichiers virtuels est directement prise en charge par systemd (/proc, /sys, /dev), binfmt_misc et HugeTBLfs sont gérés via autofs, ce qui évite d’avoir à les configurer en root ou à charger le module correspondant.
• De nombreuses petites fonctions sont prises en charge directement sans passer par le lancement d’un script : définir le nom de la machine, sauver / restaurer les données aléatoires, initialiser la localisation, nettoyer les répertoires temporaires, configurer la console, le clavier, charger des modules. Cela a pour conséquence d’unifier ces fichiers de configuration sur toutes les distributions utilisant systemd.
• Il existe un mode de démarrage interactif qui permet de confirmer chaque lancement de service en passant au noyau le paramètre « systemd.confirm_spawn=1 ».
• systemd gère le readahead qui permet d’optimiser les lectures disque au démarrage en pré‐chargeant les blocs qui vont être nécessaires par la suite (en se basant sur un enregistrement d’un démarrage précédent).

Gestion particulière

Multiples déclinaisons

Certains services ont de multiples déclinaisons: un client et un serveur peuvent être activés sur la même machine, une interface réseau virtuelle dupliquée, etc ...

Systemd implémente pour eux une variable dans le nom du fichier afin de les différencier.

client est le nom du fichier de configuration à charger dans <path>/etc/openvpn</path> (sans l'extension .conf)

systemctl start openvpn@client.service

Service fonctionnant avec xinetd

Il est possible de remplacer xinetd par systemd. Le symbole @ à la fin du nom de l'unité de service indique à systemd que le service est démarré par la socket.

<path>/usr/lib/systemd/system/amanda@.service</path>

[Unit]
Description=Amanda Backup System
After=local-fs.target

[Service]
User=amandabackup
Group=disk
ExecStart=/usr/sbin/amandad -auth=bsdtcp amdump amindexd amidxtaped
StandardInput=socket

<path>/usr/lib/systemd/system/amanda.socket</path>

[Unit]
Description=Amanda Activation Socket

[Socket]
ListenStream=10080
Accept=true

[Install]
WantedBy=sockets.target

Le protocole TCP est ici utilisé. Afin d'utiliser UDP, il faudrait remplacer ListenStream par ListenDatagram.

Afin de démarrer Amanda

systemctl start amanda.socket

Démarrage auto

systemctl enable amanda.socket

Modification de la configuration d'un daemon

Après avoir modifier une configuration Unit, il est nécessaire d'en informer systemd avec la commande

systemctl --system daemon-reload