Passage à l'éco-système systemd sous Debian Jessie: un cas concret🔗

Après avoir réalisé quelques traductions sur systemd, il est temps de mettre vraiment les mains dans le cambouis, à savoir, de l'installer pour de bon sur un maximum de machines. Toutes mes machines fonctionnent sous Debian. Cet article a pour objet de présenter un passage de SysV à systemd comme démon de démarrage sur une machine sous Debian Jessie (testing au moment de la rédaction). Bien entendu, l'objectif est d'avoir une machine à iso-fonctionnalités, j'irai donc un peu plus loin que la simple configuration du démarrage de la machine et je vise à rendre tous mes services actifs comme sous SysV.

Depuis quelque temps déjà, j'ai des messages d'erreur à cause de systemd sur mes machines en Debian Jessie. En effet, au cours de l'été, des paquets systemd se sont installés par défaut dans Jessie. Depuis, il me manque peu de choses pour que tout systemd soit accessible…

# systemctl status
Failed to get D-Bus connection: No connection to service manager.

Indique que les binaires de systemd sont actifs mais que le démon systemd n'a pas été utilisé pour démarrer la machine. On peut régler le problème assez rapidement en installant le paquet systemd-sysv. Celui-ci permet simplement de remplacer /sbin/init par le binaire de systemd. Il n'est pas vraiment conseillé de le lancer tel quel. En effet, il y a de fortes chances pour que le passage à systemd ne se passe pas sans casser quelques services. Il vaut donc mieux procéder méthodiquement.

Avant de se lancer dans le passage à systemd, mieux vaut savoir quels sont les services disponibles et si ces derniers seront disponibles.

Voici ce dont je dispose sur mon ordinateur portable:

• Un serveur web (Apache 2.4).
• Toute ma configuration sonore repose sur alsa. Je n'ai pas Pulseaudio.
• Ma configuration réseau est inactive par défaut. Elle repose sur /etc/network/interfaces.
• Xorg utilise un pilote radeon libre.
• J'utilise VirtualBox pour lancer quelques VMs au cas où. Il utilise un module noyau configuré via DKMS.
• Mon écran de login est slim qui redirige vers i3-wm.
• J'ai une configuration ACPI très customisée pour ce portable (un Lenovo e145).
• J'ai un service rsyslog configuré par défaut (la conf du mainteneur du paquet Debian).
• J'utilise un partitionnement particulier:
• une partition / qui contient le système.
• une partition /media/data qui contient des data.
• un /home/user chiffré, monté avec pam_mount.
• Pour accélérer mon démarrage, j'utilise e4rat. Ce dernier se substitue au système d'Init pour précharger des fichiers avant de rendre la main à Init.

Rien de bien affriolant, mais il y a sans doute quelques points qui pourront poser quelques problèmes.

Si vous utilisez Debian Jessie depuis quelque temps, vous avez dû vous rendre compte que systemd est déjà installé, même si vous n'avez rien demandé et que vous vous êtes contentés de faire des aptitude safe-upgrade. En effet, comme systemd sera le système d'Init par défaut, il sera installé. A l'heure de la rédaction de cet article, c'est systemd v215 qui équipe ma machine. Une version assez récente et qui offre de nombreuses fonctionnalités et dont on attend assez de stabilité. Voici ce qui est installé par défaut:

# aptitude search systemd | grep ^i
i A libpam-systemd                  - system and service manager - PAM module
i A libsystemd0                     - systemd utility library
i A systemd                         - gestionnaire système et service
i   systemd-shim                    - shim for systemd

Pour tester systemd, rien de plus facile: il faut indiquer au bootloader qu'on souhaite l'utiliser comme système d'init en ajoutant une variable nommée init à la fin de la ligne de chargement du noyau Linux dans Grub:

linux   /boot/vmlinuz-3.16-2-amd64 root=UUID=7840a396-1ab7-4acb-869c-083d607baa0d ro  quiet init=/bin/systemd

Lors du premier boot, je peux constater que systemd lance d'autres services que ceux dont j'ai l'habitude de voir apparaître. Il s'agit essentiellement des services de l'écosystème systemd comme systemd-hostname ou systemd-journald. Pour l'instant, on s'en balance, le truc est d'avoir un système iso-fonctionnel.

Faisons donc la liste de ce qui marche:

• Xorg est lancé !
• Mon lanceur de sessions graphiques (slim) se lance correctement !
• Mon gestionnaire de fenêtres fonctionne correctement !
• Mon répertoire home chiffré est correctement accessible !
• Apache est bien lancé et j'ai accès à ses services !
• Ma carte son sous Alsa fonctionne correctement !
• Mes machines virtuelles sont accessibles via VirtualBox et le module noyau spécifique est bien fonctionnel.
• rsyslog capte bien des logs même si journald semble actif…
• Globalement, ça boote plus rapidement (gain d'environ 6 secondes comparé à un système sans e4rat).
• La mise en veille (suspend to ram) est bien plus rapide qu'avant (divisée par deux).
• L'arrêt via le bouton est beaucoup plus rapide qu'avant (divisée par deux).

Néanmoins, tout n'est pas rose:

$ systemctl status
trick
   State: degraded
    Jobs: 0 queued
  Failed: 1 units

De plus, quelques-unes de mes touches spéciales, configurées via ACPI ne fonctionnent plus. Il s'agit des touches pour régler la luminosité et de celle qui active le wifi. Néanmoins l'accès au réseau est possible via le classique ifup.

Essayons de voir ce qui plante…

# systemctl --failed
  UNIT                                            LOAD   ACTIVE SUB    DESCRIPTION
● systemd-backlight@backlight:acpi_video0.service loaded failed failed Load/Save Screen Backlight Brightness of backlight:acpi_video0

La seule unité systemd qui ne fonctionne pas est liée à un problème de configuration du contrôle de la luminosité de mon ordinateur portable. Le problème se situe au niveau du noyau qui ne gère pas correctement cet élément. C'est un problème connu et que j'ai toujours ignoré jusqu'à présent car j'ai d'autres moyens pour gérer la luminosité sur cette machine. On peut donc dégager cette unité qui ne me sert pas.

# systemctl mask systemd-backlight@backlight:acpi_video0.service

Reste ensuite, le problème des touches ACPI. Sur cette machine, j'ai une batterie de scripts spécifiques qui sont activés lors de la frappe sur les touches situées en haut du clavier du Lenovo e145. Après le passage à systemd, j'ai pu remarquer que ces touches ne fonctionnent plus. En fait, en allant plus loin, on peut remarquer qu'il me suffit de lancer une opération qui a besoin de l'ACPI pour qu'elles se remettent à fonctionner. C'est le cas lorsque je lance l'utilitaire acpi_listen.

Ce comportement m'oriente vers un problème lié à l'activation par socket de systemd. On dirait que le service ne se lance pas normalement. En revanche dès qu'un programme s'adresse à la socket, le service est à nouveau opérationnel. Il doit donc y avoir un problème d'activation de socket lors de l'appui initial d'une touche ACPI.

Après avoir passé quelque temps à chercher une solution sur Internet, je me suis dit qu'il fallait plus simplement activer acpid par défaut et qu'il y avait sans doute un élément de conf non prise en charge par systemd. J'ai donc tout simplement manuellement activé acpid.socket et acpid.service:

# systemctl enable acpid.socket
# systemctl enable acpid.service
Synchronizing state for acpid.service with sysvinit using update-rc.d…
Executing /usr/sbin/update-rc.d acpid defaults
Executing /usr/sbin/update-rc.d acpid enable

Après reboot, mes touches ACPI redeviennent fonctionnelles !

e4rat permet d'accélérer le processus de boot en préchargeant un ensemble de fichiers en RAM. Il semble compatible avec systemd. Vous aurez besoin de relancer une opération de collecte, car il est évident que le passage à systemd implique de précharger les fichiers relatifs à systemd (les binaires des démons notamment). Vous devrez donc booter votre machine avec e4rat-collect (cf la doc de e4rat pour plus de détails sur cette opération).

Une fois la collecte terminée, il reste à indiquer à e4rat de passer la main systemd à la place du binaire Init classique. Vous pouvez le faire en modifiant le fichier /etc/e4rat.conf en modifiant la variable init:

; path to init process binary (DEFAULT: /sbin/init)
init /bin/systemd

Une fois activée, cette option vous permettra de démarrer avec systemd comme d'habitude. Le processus de boot sera encore accéléré, vous bénéficierez à la fois du préchargement des fichiers et de la forte parralélisation de systemd.

On peut voir dans cet article que le passage à systemd sous Debian Jessie se réalise plutôt facilement. Il y a finalement assez peu de modifications de la configuration pour obtenir un système iso-fonctionnel à celui qui démarre avec sysvinit. C'est plutôt encourageant pour la suite et montre qu'un bon travail de configuration a été mené en amont par les empaqueteurs de systemd sous Debian.

Néanmoins, le cas que nous avons pu étudier reste relativement simple. En effet, dans notre exemple, il y a peu de services spécifiques et la majorité des unités systemd qui sont lancées sont génériques et relatives à l'écosystème systemd. Pour aller plus loin, on pourrait se lancer dans la conversion d'une machine qui disposerait de davantage de services réseau. Un vrai serveur serait une cible d'étude d'intérêt et révèlerait sans doute plus d'adaptation de configuration.

Dans tous les cas, plus il y aura d'administrateurs systèmes qui tenteront le passage à systemd, plus nous aurons de retour d'expérience sur le sujet et plus facilement nous pourrons sortir des impasses techniques amenées par systemd… À vous de jouer !