systemd - Administration du système et des services

Contents

  1. systemd - Administration du système et des services
    1. Introduction
    2. Usage basique
      1. Obtenir des informations sur le statut du système
      2. Gérer les services
      3. Créer ou modifier des services
      4. Petits ajustements
    3. Installer et tester
      1. Installation
      2. Configurer pour test
      3. Configurer comme init par défaut
    4. Déboguer
      1. Unités échouées
      2. systemd échoue au démarrage ou à l'extinction
      3. Debug du noyau sans le debug de systemd dans Jessie
    5. Bugs et Bug-Tracking-Systems
    6. Problèmes connus et solutions
      1. Points de montage de type « bind » partagés
      2. Le session SSH ne se termine pas correctement à l'extinction/redémarrage
      3. Messages au démarrage manquants dans la console(tty1) après le démarrage
      4. Changements de console virtuelle et série
      5. Processus orphelins
    7. Où obtenir de l'aide?
    8. Installation sans systemd
    9. Ressources Debian
    10. Autres ressources

Introduction

systemd est un gestionnaire de système et de services pour Linux. Il est le système d'init par défaut dans Debian depuis Debian 8 (« Jessie »). Systemd est compatible avec les scripts d'init SysV et LSB. Il peut fonctionner comme un remplaçant de sysvinit. Systemd :

Systemd s'exécute comme démon en tant que PID 1.

Les taches de systemd sont organisées en tant qu'unités. Les unités les plus courantes sont les services (.services), les points de montage (.mount), les périphériques (.device), les sockets (.socket) ou les minuteurs (.timer). Par exemple, le démarrage du démon shell sécurisé est effectué par l'unité ssh.service.

Systemd place chaque service dans un groupe de contrôle (cgroup) dédié au service. Les noyaux modernes prennent en charge l'isolation des processus et l'allocation des ressources en fonction des groupes de contrôle.

Les cibles (targets) sont des groupes d'unités. Les cibles appellent les unités pour assembler le système. Par exemple, graphical.target appelle toutes les unités nécessaires pour démarrer un poste de travail avec une interface utilisateur graphique. Les cibles peuvent se superposer ou dépendre d'autres cibles. Au démarrage, systemd active la cible default.target qui est un alias pour une autre cible telle que graphic.target.

Systemd crée et gère les sockets utilisés pour la communication entre les composants du système. Par exemple, il crée d'abord le socket /dev/log puis démarre le démon syslog. Cette approche présente deux avantages. Premièrement, les processus communiquant avec syslog via /dev/log peuvent être démarrés en parallèle. Deuxièmement, les services écrasés peuvent être redémarrés sans que les processus qui communiquent via les sockets avec eux perdent leur connexion. Le noyau mettra la communication en mémoire tampon pendant que le processus redémarre.

Voir la page du site officiel pour plus d'information.

Usage basique

systemctl est l'outil principal utilisé pour inspecter et contrôler l'état du système « systemd » et du gestionnaire de service. Vous pouvez par exemple utiliser systemctl pour activer/désactiver les services de manière permanente ou uniquement pour la session en cours. Reportez-vous à la page de manuel systemctl(1) pour plus de détails.

Obtenir des informations sur le statut du système

Afficher le statut du système : 

$ systemctl status

Lister les unités échouées : 

$ systemctl --failed

Lister les fichiers unités installés : 

$ systemctl list-unit-files

Gérer les services

Lister tout les services en cours d'exécution : 

$ systemctl

Activer le service « example1 » immédiatement : 

# systemctl start example1

Désactiver le service « example1 » immédiatement : 

# systemctl stop example1

Redémarrer le service « example1 » immédiatement : 

# systemctl restart example1

Voir le statut du service « example1 » : 

# systemctl status example1

Activer « example1 » pour être lancé au démarrage : 

# systemctl enable example1

Désactiver « example1 » pour ne pas être lancé au démarrage : 

# systemctl disable example1

Créer ou modifier des services

Les unités sont définies par des fichiers de configuration individuels appelés fichiers unités. Le type de l'unité est reconnu par le suffixe du nom de fichier, .mount dans le cas d'un point de montage. Les fichiers unités fournis par Debian sont situés dans le répertoire /lib/systemd/system. Si un fichier d'unité locale nommé de manière identique existe dans le répertoire /etc/systemd/system, il aura priorité et systemd ignorera le fichier dans le répertoire /lib/systemd/system. Certaines unités sont créées par systemd sans fichier d'unité existant dans le système de fichiers.

Les administrateurs système doivent placer des fichiers d'unités personnalisés dans /etc/systemd/system.

Pour de petites personnalisations apportées à un fichier unité, les administrateurs système doivent utiliser la fonctionnalité de « répertoire drop-in » (documentée dans systemd.unit(5)).

Voici un exemple : 

# cat /etc/systemd/system/name.service.d/local.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/name-service --my-options

Pour plus d'informations concernant l'écriture de vos propres services, consultez systemd/Services.

Petits ajustements

* Utilisez la commande # systemctl edit name.service pour créer ou modifier un fichier /etc/systemd/system/name.service.d/override.conf et apportez les modifications nécessaires.

Installer et tester

Systemd était inclus dans Debian Wheezy comme une technologie de test. Soyez sûr que vous utilisez Debian Jessie ou supérieur pour avoir une version récente de systemd.

Installation

Pour installer systemd lancez : 

# apt-get update
# apt-get install systemd

Cela va installer le paquet systemd mais ne le configurera pas comme système d'init par défaut.

Configurer pour test

Pour tester systemd avant de le basculer comme init par défaut, vous pouvez ajouter les paramètres de démarrage suivant au noyau : 

init=/lib/systemd/systemd

Cela peut être fait dans le menu de Grub pour un démarrage unique - Pressez « e » dans le menu GRUB et ajoutez ceci à la ligne qui concerne le noyau. Par exemple, en fonction des options requises pour votre système particulier, cela pourrait ressembler à ça : 

linux /vmlinuz-3.13-1-amd64 root=/dev/mapper/root-root init=/lib/systemd/systemd ro quiet

Si le PID 1 est systemd c'est que votre système fonctionne avec systemd.

Configurer comme init par défaut

Afin d'utiliser systemd vous devriez aussi installer le paquet systemd-sysv qui fournit des liens symboliques pour /sbin/init. Il est recommandé d'exécuter ceci lorsque vous êtes déjà sous systemd, comme décrit dans la section précédente. 

# apt-get install systemd-sysv

Afin de démarrer votre système avec le systemd nouvellement installé, redémarrez simplement. 

# reboot

Si vous utilisez un noyau compilé par vos soins, assurez vous que vous avez un 2.6.39 ou plus récent et activez les options suivantes : 

 * CONFIG_DEVTMPFS=y
 * CONFIG_CGROUPS=y
 * CONFIG_AUTOFS4_FS=[y|m]
 * CONFIG_IPV6=[y|m], optional, but highly recommended
 * CONFIG_FANOTIFY=y, optional, required for systemd readahead. available in Linux kernel >= 2.6.37.

Pour une liste à jour, regardez la section « REQUIREMENTS » dans le fichier README de l'upstream.

Déboguer

Unités échouées

Dans certains cas des unités entrent dans un état d'échec (failed state). La commande status peut être utilisée pour obtenir quelques détails : 

$ systemctl status <UNITNAME>

Les unités échouées peuvent être manuellement nettoyées : 

# systemctl reset-failed

systemd échoue au démarrage ou à l'extinction

Parfois il est nécessaire d'enquêter pour comprendre pourquoi systemd ralentit au démarrage ou à l'extinction.

Solution #0 : Supprimer la mention « quiet » de la ligne de commande du noyau (Aussi appelée « cmdline » ou « grub line »).

Solution #1 : Augmenter la verbosité via la cmdline : Ajouter « systemd.log_target=kmsg systemd.log_level=debug » Bien sûr il est possible de le faire de manière temporaire : 

[ /etc/default/grub ]
GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug" <--- à ajouter ici (en commentant/décommentant vous pouvez faciler basculer en mode de débogue)

# update-grub

Solution #2 : Augmenter la verbosité via /etc/systemd/system.conf 

LogLevel=debug           <--- Décommentez cette ligne et utilisez la mention « debug » (par défaut elle est commentée avec valeur « info »)
LogTarget=syslog-or-kmsg <--- Décommentez cette ligne (par défaut elle est commentée)

Solution #3 : Démarrez un shell d'urgence : ajoutez systemd.unit=rescue.target ou juste 1 (le chiffre un) à la ligne de commande du noyau.

Solution #4 : Activez le shell d'urgence : Lancez systemctl enable debug-shell.service. (Vous pouvez le faire dans un environnement chroot après avoir démarré un système de récupération.) Cela démarre un shell root dans le TTY 9.

CONSEILS : « man systemd » et « man systemd-system.conf »

CONSEILS : Des informations plus poussées pour déboguer sont accessibles sur cette page FreeDesktop.

CONSEILS : Comment vérifier les paramètres/options en ligne de commande du noyau? 

# cat /proc/cmdline

Voir les notes sur le niveau de log (voir systemd(1) et systemd-system.conf(5)) :

« Set log level. As an argument this accepts a numerical log level or the well-known syslog(3) symbolic names (lowercase): emerg, alert, crit, err, warning, notice, info, debug. »

CONSEILS : Gardez une copie du /sbin/init pour le paquet sysvinit en cas de récupération (Vous pourrez utiliser init=/sbin/init.sysvinit dans cmdline)! 

# cp -av /sbin/init /sbin/init.sysvinit <--- Avant d'installer le paquet systemd-sysv

Voir aussi https://fedoraproject.org/wiki/How_to_debug_Systemd_problems

Debug du noyau sans le debug de systemd dans Jessie

Le fait d'utiliser le vieux paramètre « debug » du noyau dans Jessie activera aussi le mode « debug » de Systemd. Afin d'avoir l'ancien comportement, n'utilisez pas « debug », mais plutôt le paramètre du noyau « loglevel=7 ».

Bugs et Bug-Tracking-Systems

Problèmes connus et solutions

Points de montage de type « bind » partagés

Le comportement par défaut d'un point de montage « bind » change avec systemd. Le noyau établit les points de montage bind de tout ce qui est situé sous / PRIVATE. Systemd change cela à SHARED.

Donc, quand vous faites ceci : 

    mount --bind / $CHROOT
    mount --bind /dev/ $CHROOT/dev
    umount $CHROOT/dev

/dev sera démonté de votre système de base/parent là aussi!

Ce que vous pouvez faire à la place est : 

    mount --bind --make-rslave / $CHROOT
    mount --bind --make-rslave /dev/ $CHROOT/dev

Cela va propager les changements de montage (ainsi que les options de montage) dans le système de base/parent dans le $CHROOT mais pas depuis le $CHROOT vers le parent.

La justification pour ce changement de comportement par défaut peut être trouvé dans ce bogue : 739593, en particulier dans le commentaire de Lenart.

Le session SSH ne se termine pas correctement à l'extinction/redémarrage

Si vous tentez de redémarrer/éteindre une machine distance par ssh, vous pourriez constater que votre session ne se termine pas correctement, vous laissant avec un terminal inactif jusqu'à l'expiration d'un long délai d'inactivité. Il existe un bogue 751636 à ce sujet. Pour l'instant, la solution de contournement à ce problème est d'installer : 

    apt-get install libpam-systemd

cela terminera la session ssh avant que le réseau ne tombe. Veuillez noter qu'est nécessaire que PAM soit activé dans sshd.

Messages au démarrage manquants dans la console(tty1) après le démarrage

Avec systemd la console(tty1) est traitée différemment et si vous aviez l'habitude de vérifier comment se réalise le démarrage, vous vous retrouvez maintenant avec seulement quelques lignes non informatives.

Pour être en mesure d'obtenir la transcription complète de l'amorçage du système sur votre console, vous devez effectuer deux étapes.

1. Ajoutez les options de noyau systemd.show_status=1, par exemple via /etc/default/grub : 

    GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.show_status=1"

et exécutez update-grub2.

2. Créez le fichier /etc/systemd/system/getty@tty1.service.d/noclear.conf avec le contenu suivant : 

[Service]
TTYVTDisallocate=no

afin de désactiver l'effacement du terminal à l'invocation de getty.

Changements de console virtuelle et série

Ceux habitué à changer inittab pour activer/désactiver les consoles séries ou virtuelles noterons que ce ficher a disparu pour une installation neuve. Tout est désormais géré directement de systemd. Par exemple, vous pouvez activer une console série sur COM1 avec : 

systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service

Cependant, il est généralement préférable d'ajouter console=ttyS0 sur la ligne de commande du noyau, car cela active aussi la sortie du noyau sur les redémarrages. Par exemple, dans le cas de GRUB, cela se fait en ajoutant à /etc/default/grub : 

GRUB_CMDLINE_LINUX="console=ttyS0"

… et en lançant update-grub. Ce changement prendra effet à partir du prochain redémarrage.

Notez également que Linux prend en charge plusieurs consoles pour la sortie, mais une seule pour l'entrée. La dernière nommée (ou par défaut si aucune n'est nommée) de la ligne de commande du noyau spécifie laquelle est utilisée pour l'entrée, et toutes sont utilisées pour la sortie. Par exemple, pour GRUB : 

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0"

Cela fait, après avoir exécuté update-grub et redémarré, permettra une entrée de console depuis /dev/ttyS0 et une sortie vers celle-ci et /dev/tty0. Notez également que les paramètres de série peuvent également être spécifiés, par exemple : 

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,9600n8"

Processus orphelins

Puisqu'il gère les sessions utilisateurs (prenant le rôle de X ou d'autres composants), systemd peut changer significativement la façon dont les processus survivent à une déconnexion. Par défaut, lorsque X s’étend tous les processus doivent se terminer et systemd nettoiera la session, mais il y a quelques cas marginaux où certains processus ne le font pas correctement.

Vous pouvez configurer la façon dont systemd gère les processus restants avec le paramètre KillUserProcesses= dans logind.conf. En définissant cela à yes, les processus sont terminés de force lorsque la session se termine. Notez que cela cassera les outils tels que screen ou tmux, à moins qu'ils aient été configurés pour se lancer sous une unité user@.service distincte et si enable-linger est défini à yes dans loginctl. Une manière simple de faire cela est d'exécuter le programme dans un « transient scope » en utilisant systemd-run : 

systemd-run --scope --user screen

Maintenant, les sessions devraient normalement nettoyer dernière elles, et de tels problèmes devraient être résolus sans avoir à recourir à KillUserProcesses=yes.

Une bonne façon de lister les processus affectés est de les grouper par « control group » avec la commande systemd-cgls : 

systemd-cgls

Quelques applications connues pour rencontrer ce problème :

Où obtenir de l'aide?

Systemd est un projet jeune avec une forte orientation pour résoudre les problèmes indépendamment du type de distribution.

Canaux spécifiques à Debian :

Plusieurs autres distributions utilisent systemd

Installation sans systemd

Jessie installe systemd par défaut sur toutes nouvelles installations. Si vous désirez l'installer sans systemd, c'est à dire qu'il utilise sysvinit-core à la place (anciennement sysV5 init), il est possible d'utiliser la pré-configuration (preseed) pour remplacer systemd avec sysvinit à la fin de l'installation (Cela ne fonctionnera probablement pas si l'on sélectionne l'un des environnements de bureau qui nécessite systemd pour des fonctionnalités spécifiques). Si on utilise déjà un fichier de pré-configuration, assurez vous juste d'avoir les valeurs suivantes : 

preseed/late_command="in-target apt-get install -y sysvinit-core"

Si l'on n'utilise pas de fichier de pré-configuration, on pourra le rajouter aux options de démarrage à la place en appuyant sur TAB lors du menu de démarrage. Sur l'entrée désirée on ajoutera la ligne de pré-configuration citée ci-dessus à la fin de la ligne de commande de démarrage.

Il pourra rester quelques éléments de systemd installés, mais au moins l'init en lui-même ne sera pas systemd et le nettoyage des éléments restant ne devrait pas être trop difficile.

Ressources Debian

Autres ressources

CategoryPermalink