runlevel 5). C'est l'unit d clench e en

premier.

unit s invoqu es au d marrage ou lors de

l'arr t du syst me ou quand l'ordre

correspondant est donn par la commande

systemctl (voir 4).

unit s invoqu es tr s t t lors du d marrage

et ind pendamment du runlevel. L'activation

du LVM en est un exemple.

(o X prend les valeurs 0 6) permet de

simuler les changements de runlevel. Ces

unit s sont en fait des liens symboliques vers

poweroff.target (niveau 0), rescue.target

local-fs.target,

remote-fs.target,

swap.target

network.target

(niveau 1), multi-user.target (niveaux 2,3,4),

graphical.target (niveau 5) et reboot.target

(niveau 6).

pour le montage des syst mes de fichiers et

l'activation du swap.

pour g rer correctement les d pendances

entre les services et le r seau.

2.3. ORGANISATION ET SYNTAXE DES FICHIERS

DE CONFIGURATION

Si on con oit bien le besoin d'imiter le comportement de init, quoique le nombre des

unit s sp ciales soit tr s cons quent, il faut maintenant se repr senter concr tement

comment sont con ues ses fameuses unit s.

Systemd est compos de nombreux ex cutables situ s sous

/usr/lib/systemd/. D'ailleurs le premier processus, lanc par le noyau au

d marrage, est /usr/bin/systemd qui n'est autre qu'un lien symbolique vers

/usr/lib/systemd/systemd. Si vous ne vous en doutiez pas d j , vous noterez

d s pr sent que l'architecture de systemd fait un usage abondant des liens

symboliques...

La configuration est situ e dans le r pertoire /etc/systemd/ et le fichier de

configuration principal va s'appeler /etc/systemd/system.conf.

Pour conna tre l'emplacement des fichiers de configuration de systemd, il est

possible d'utiliser la commande suivante :

pkg-config systemd --variable=systemdsystemconfdir

/etc/systemd/system

Note

Note 1 : systemd peut tre invoqu par un utilisateur avec l'option --user, dans ce

cas, son fichier de configuration principal est /etc/systemd/user.conf, mais

nous occulterons cette possibilit ici.

Note 2 : Sur la distribution Fedora 17, utilis e ici comme exemple, les r pertoires

/bin, /sbin et /lib sont en fait des liens symboliques sur /usr/bin,

/usr/sbin et /usr/lib.

Le fichier /etc/systemd/system.conf est un fichier la .INI , contenant

une rubrique et des options globales, dont les principales sont list es

dans ce tableau :

Param tre

Description

Valeur par

d faut

LogLevel

LogTarget

MountAuto

MountSwap

d finit le niveau de verbosit .

destination des messages de

logs. Une valeur usuelle est

journal, qui exploite un

processus suppl mentaire

(voir 3.2).

honore les montages de

syst mes de fichiers list s

dans /etc/fstab.

honore l'activation des zones

de swap list es dans

/etc/fstab.

choix du cgroup.

info

syslog

yes

yes

DefaultController

s

Certaines options peuvent tre surcharg es en passant des options au noyau ou sur la

ligne de commandes systemd. Par exemple, en cas de probl me, systemd propose

un mode pas- -pas pour permettre la r solution des probl mes si vous lui passez le

param tre systemd.confirm_spawn=1 comme option du noyau, ou --

confirm-spawn sur sa ligne de commandes.

cpu

systemd analyse ensuite le contenu du fichier bien nomm

/etc/systemd/system/default.target qui, sur la Fedora 17 lanc e en

mode graphique, est un lien symbolique vers

/lib/systemd/system/runlevel5.target. Enfin du concret ! Nous

pouvons examiner le contenu de ce fichier et commencer explorer la syntaxe des

fichiers de configuration des unit s.

Notez que sur votre distribution, pour conna tre l'emplacement des fichiers de

configuration des unit s, il est possible d'utiliser la commande suivante :

pkg-config systemd --variable=systemdsystemunitdir

/usr/lib/systemd/system

Si les fichiers qui sont sous /etc/systemd/system/ sont en fait des liens

symboliques sur leurs homonymes situ s sous /lib/systemd/system/, certains

r pertoires existent avec le m me nom la fois sous les r pertoires

/etc/systemd/system/ ET /lib/systemd/system/, et dans ce cas leur

contenu diff re. L'affichage de la valeur de la variable systemdsystemunitpath

avec la commande pkg-config montre bien que le r pertoire

/etc/systemd/system/ est prioritaire.

Un fichier de configuration d'unit contient les rubriques suivantes :

Nom de la rubrique Description

d crit le service et les r gles de d pendances l'aide des

param tres :

Description, Before, After, Requires, Requisite, Wants,

Condition*.

d crit ce qu'il faut faire quand on invoque

systemctl enable | disable. Par exemple, le

param tre WantedBy=xxxx indique qu'il faudra

cr er un lien symbolique dans le r pertoire

/etc/systemd/system/xxxx.wants/. Also

indique des unit s additionnelles installer en

plus.

Puis, selon le type de l'unit , des sections suppl mentaires et leurs lots de param tres

seront n cessaires.

2.4. EXEMPLES DE CONFIGURATION

tout seigneur tout honneur, examinons le contenu du fichier

/etc/systemd/system/default.target qui est le nom de la premi re unit

lanc e par systemd (pour information, je suis un adepte de la commande

readlink qui permet de conna tre le nom final du fichier r f renc par une suite de

liens symboliques) :

readlink -f /etc/systemd/system/default.target

/lib/systemd/system/graphical.target

cat /etc/systemd/system/default.target

Description=Graphical Interface

Documentation=man:systemd.special(7)

Requires=multi-user.target

After=multi-user.target

Conflicts=rescue.target

AllowIsolate=yes

Alias=default.target

Nous retrouvons bien les sections et dont nous avons parl au

2.3. Le param tre Requires= indique que l'unit multi-user.target doit tre

activ e pour que default.target soit consid r e comme active. Le param tre

After= pr cise qu'il faut attendre la fin de l'ex cution de l'unit multi-

user.target avant de finir l'ex cution de default.target (il existe aussi un

param tre Before=, mais en l'absence de pr cision sur l'ordonnancement, les

ex cutions sont parall lis es).

Le param tre Conflicts= indique que l'unit default.target ne doit pas tre

lanc e si rescue.target est d j activ e. L'unit rescue.target correspond

au runlevel 1, il est normal de ne pas lancer le mode multi-utilisateur et encore moins

l'interface graphique !

Le param tre AllowIsolate= est un hack : il permettra de faire en sorte qu'on

puisse imiter le changement de niveau d'ex cution comme on le faisait avec init.

Dans le cas d'un changement de runlevel, donc, tous les processus qui ne seront pas

g r s par l'unit default.target ou ses d pendances seront arr t s.

Le param tre Alias= de la rubrique indique que lors de l'activation de

cette unit (dont le v ritable nom est runlevel5.target), il faudra cr er un alias

sous la forme d'un lien symbolique nomm default.target ! Eh oui : autant

d crire tous les liens symboliques dans des fichiers de configuration et laisser les outils

fournis avec systemd g rer correctement ces liens.

Reprenons : default.target doit tre activ e apr s multi-user.target.

Que fait cette unit ?

cat /lib/systemd/system/multi-user.target

Description=Muti-User

Documentation=man:systemd.special(7)

Requires=basic.target

Conflicts=rescue.service rescue.target

After=basic.target rescue.service rescue.target

AllowIsolate=yes

Alias=default.target

Vous commencez comprendre le m canisme ? On nage en pleine r cursivit : cette

unit d pend de basic.target, mais un moment donn , il faudra bien lancer des

processus ! Notons que la rubrique d finit un Alias qui porte le m me

nom que celui d fini par l'unit graphical.target : ce n'est pas un probl me car

l'unit graphical.target se jouant apr s multi-user.target, le lien

symbolique default.target pointera bien vers la bonne unit .

En continuant l'examen des unit s selon leurs d pendances, on constate que

basic.target d pend de sysinit.target et sockets.target. La

configuration de sysinit.target contient un nouveau param tre int ressant :

...

Wants=local-fs.target swap.target

On se doute qu'il va falloir d'abord activer les syst mes de fichiers locaux ainsi que le

swap avant de r aliser d'autres t ches, mais ici, Wants= indique que l'unit

sysinit.target sera activ e m me si l'une des unit s dont elle d pend choue

lors de son activation. Ce comportement est diff rent du Requires= qui stipule que

l'unit n'est activ e que si toutes les unit s dont elle d pend sont activ es avec succ s

(c'est une forme de transaction !).

Parfois, une unit peut d pendre de tr s nombreuses autres unit s, ce qui provoquerait

l' criture de directives Wants= ou Requires= assez fastidieuses avec le souci de

devoir modifier ces lignes chaque fois que les d pendances sont modifi es. Pour viter

cela, systemd permet d'externaliser les d pendances d'une unit en permettant

l'utilisation de r pertoires associ s des liens symboliques (encore !). Le principe est

le suivant (nous le d crivons pour la directive Wants=, il se transpose ais ment pour

la directive Requires=) :

Prenons l'exemple de l'unit sysinit.target, elle d pend de local-

fs.target et swap.target, comme indiqu par son fichier de configuration,

mais ce n'est pas tout ! Comme il existe un r pertoire nomm

/etc/systemd/system/sysinit.target.wants/, l'unit

sysinit.target d pend aussi de toutes les unit s dont le nom appara t dans les

liens symboliques situ s dans ce r pertoire :

cd /etc/systemd/system

ls -l sysinit.target.wants

...

lvm2-monitor.service -> /usr/lib/systemd/system/lvm2-

monitor.service

...

mdmonitor-takeover.service -> /usr/lib/systemd/system/mdmonitor-

takeover.service

Les d pendances se r glent donc simplement coups de cr ation et destruction de

liens symboliques. R le parfaitement rempli par la commande systemctl que nous

verrons dans un instant.

Prenons un autre exemple : comment est lanc le d mon sshd ? Il est d crit par

l'unit /lib/systemd/system/sshd.service qui est r f renc e par un lien

symbolique situ sous /etc/systemd/system/multi-

user.target.wants/. Le contenu du fichier sshd.service est :

Description=OpenSSH server saemon

After=syslog.target network.target auditd.service

EnvironmentFile=/etc/sysconfig/sshd

ExecStartPre=/usr/sbin/sshd-keygen

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecReload=/bin/kill -HUP $MAINPID

WantedBy=multi-user.target

Oui, un service dispose d'une nouvelle rubrique nomm e dont les

param tres sont explicites. Toutefois, il manque ici le param tre Type= qui indique

comment lancer le service. La valeur par d faut est simple pour indiquer que le

processus nomm par ExecStart= est le processus principal du service, mais les

autres possibilit s sont : forking, dbus, oneshot, idle et notify (voir la

documentation man systemd.service). Remarquez aussi la ligne de commandes

qui permet de faire un reload du d mon : la variable $MAINPID est g r e par

systemd et aura pour valeur le PID de sshd.

Dans la configuration de l'unit sshd.service, on trouve aussi la directive

WantedBy= qui indique la d pendance entre ce service et l'unit multi-

user.target, ce qui n cessitera la cr ation d'un lien symbolique dans

/etc/systemd/system/multi-user.target.wants/ lors de

l'initialisation des unit s.

La configuration des services permet aussi d'imiter la fonctionnalit du respawn

propos e par init. Avec systemd, la surveillance et la reg n ration d'un processus

de service est r alis e par les directives Restart= (sur quel tat du processus faut-il

le relancer ?) et RestartSec= (au bout de combien de secondes faut-il le relancer

?). Regardez le contenu de la configuration de l'unit [email protected] pour en

avoir un exemple.

Avez-vous remarqu la pr sence du caract re @ dans le nom de l'unit

[email protected] ? Il s'agit d'une astuce lexicale propos e par systemd pour

permettre de cr er des mod les d'unit s (unit templates). En effet, vous savez

qu'habituellement vous disposez d'un certain nombre de terminaux virtuels, chacun

tant g r par une commande de la famille getty (par exemple, sur RedHat cette

commande est /sbin/mingetty voir dans le fichier /etc/inittab). Pour

imiter ce comportement, il faudrait donc d finir autant d'unit s que de terminaux

virtuels g rer, ce qui est videmment viter. Les mod les d'unit s prennent tout

leur sens alors :

si systemd doit activer une unit dont le nom est [email protected] et que

ce nom d'unit n'existe pas sous /lib/systemd/system/, alors, cause de la

pr sence du caract re @ dans le nom de l'unit , systemd va rechercher une unit dont

le nom est [email protected]. Comme cette unit existe, c'est elle qui sera invoqu e

et la cha ne tty1 qui faisait partie du nom de l'unit initiale sera fournie sous forme

de specifier accessible dans la configuration de l'unit . Ce specifier se nomme %I

(lire i majuscule. Il en existe d'autres voir man systemd.unit).

Voici un extrait du fichier [email protected] sur Fedora17 :

Description=Getty on %I

...

Restart=always

RestartSec=0

TTYPath=/dev/%I

...

Outre les services, au sens classique du terme, nous avons dit en pr ambule que

systemd allait aussi g rer les sockets afin d'acc l rer les lancements des processus

inter-d pendants. Regardons la syntaxe de configuration d'une unit de type Socket,

par exemple cups.socket :

Description=CUPS Printing Service Sockets

ListenStream=/var/run/cups/cups.sock

ListenStream=631

ListenDatagram=0.0.0.0:631

WantedBy=sockets.target

Nous constatons la pr sence d'une rubrique contenant les param tres de

cr ation des sockets cr er. Ici, systemd va cr er une socket du domaine UNIX qui

s'appellera /var/run/cups/cups.sock, puis une socket TCP

(ListenStream) l' coute sur le port 631 pour toutes les adresses IP de la machine,

puis il cr era une socket UDP (ListenDatagram) l' coute du port 631 en IPv4

uniquement. D'autres param tres sont disponibles (voir man systemd.socket).

Comme ultime exemple, nous allons prendre l'exemple d'un montage effectuer lors

du d marrage. Il m'arrive souvent de placer ce type de montage dans le v n rable

/etc/rc.local, mais le faire g rer par systemd est un gage de robustesse. Sur

notre Fedora 17, le contenu du fichier media.mount est :

Description=Media Directory

Before=local-fs.target

:

What=tmpfs

Where=/media

Type=tmpfs

Options=mode=755,nosuid,nodev,noexec

Ce qui permet d'avoir au d marrage un r pertoire /media associ un syst me de

fichiers de type tmpfs.

Comme vous le subodorez peut- tre d j , le nombre de param tres possibles pour

d finir la configuration des unit s est tr s important, ce qui fait la fois la richesse et

la complexit de systemd !

2.5. PETITE SYNTH SE

R capitulons en prenant comme exemple le d marrage du syst me :

Lorsque systemd est lanc par le noyau (1), il lit son fichier

/etc/systemd/system.conf (2), puis il examine la premi re unit lancer :

default.target (3) qui est en r alit un lien symbolique vers

runlevel5.target (lui-m me lien symbolique vers graphical.target).

Ce fichier contient une directive After=multi-user.target, donc systemd

cherche la configuration de cette unit (4) et l'interpr te. Mais il existe un r pertoire

multi-user.target.wants (5), donc systemd parcourt ce r pertoire pour

activer les unit s qui y sont d crites. On y trouve par exemple sshd.service, etc.

3. GESTION DES PROCESSUS ET DES LOGS

3.1. GESTION DES PROCESSUS

Par d faut, systemd maintient automatiquement la relation entre PID et processus

activ s. Ainsi, le PID de notre d mon sshd pr c dent est stock par systemd dans

le fichier /var/run/sshd.pid. Mais pour les services dont la valeur de Type=

est forked (alors que le type est simple pour sshd.service), systemd peut

se tromper dans son analyse du processus principal. En effet, quand un service est de

type forked, cela signifie que le processus lanc par systemd va lancer un ou

plusieurs processus fils puis va se terminer. S'il a lanc plusieurs processus fils, le

stockage de PID du processus fils principal est la charge du processus parent et il

faut indiquer systemd dans quel fichier est stock ce PID. On fait pour cela un

usage de la directive PIDFile= dans le fichier de configuration de l'unit .

Note

sur Fedora 17, le r pertoire /var/run est en fait un lien symbolique vers /run qui

est le point de montage d'un syst me de fichiers de type tmpfs, donc rapide mais non

persistant.

3.2. GESTION DES LOGS

Dans le tableau du 2.3, nous avons montr les param tres principaux de systemd

dans le fichier /etc/systemd/system.conf. Parmi ceux-ci, nous avons voqu

LogTarget=. Sur Fedora 17, la valeur de ce param tre est : journal. Cela indique

systemd d'envoyer tous les messages de log un nouveau d mon nomm

systemd-journald lui-m me activ par systemd car d crit par l'unit

systemd-journald.service.

Ce processus est configur par le fichier /etc/systemd/systemd-

journald.conf dont voici un extrait :

ForwardToSyslog=yes

MaxLevelSyslog=debug

Compress=yes

#SystemMaxUse=

#ForwardToConsole=no

Le processus systemd-journald stocke les logs qu'il re oit dans des fichiers

situ s sous /run/log/journal/, mais il peut aussi r mettre les logs vers le

d mon syslog (ou rsyslog dans notre cas) ou vers la Console syst me. On peut

lui indiquer des tailles limites de fichiers g n rer ou une taille maximale d'espace

disque utiliser.

Les fichiers de logs sont un format binaire, il faut utiliser la commande

journalctl pour en afficher le contenu :

journalctl

affiche le contenu des logs avec votre paginateur pr f r , mais il est possible de limiter

le nombre de lignes affich es avec l'option -n (comme le fait la commande tail) :

journalctl -n 10

Enfin, l'affichage peut tre filtr (comme le ferait grep !) en pr cisant des valeurs

sp cifiques pour les champs des lignes de logs. Ces champs ont des noms pr d finis

comme MESSAGE, PRIORITY, _PID, _HOSTNAME, _SYSTEMD_UNIT (voir man

systemd.journal-fields). Par exemple, pour n'afficher que les logs relatifs

l'unit sshd.service, on ex cute la commande :

journalctl _SYSTEMD_UNIT=sshd.service

4. COMMENT FAIRE COMME AVANT, AVEC

INIT ?

Finalement, 30 ans apr s, Unix/Linux ne change pas radicalement : on peut g rer

systemd avec les commandes ln pour les liens symboliques et vi pour la

configuration ! N anmoins, essayons d' tre un peu plus productifs et vitons de

r crire des commandes qui existent d j . Si, comme moi, vous vous tes habitu aux

commandes simples mais n anmoins utiles chkconfig et service, par quoi va-t-il

falloir les remplacer ?

Voici un petit tableau qui met en parall le vos commandes usuelles avec leur pendant

la mode de systemd :

Remplacement de la commandechkconfig

chkconfig sshd on

chkconfig sshd off

chkconfig sshd --list

Remplacement de la commande service

service sshd status

systemctl enable sshd.service

systemctl disable sshd.service

systemctl is-enabled sshd.service

systemctl status sshd.service

service sshd status

service sshd start

systemctl start sshd.service

service sshd start

service sshd stop

systemctl stop sshd.service

service sshd stop

service sshd reload

systemctl reload sshd.service

service sshd reload

Remplacement des commandesinitettelinit

init 0

systemctl poweroff

init 6

init 3

init 0

systemctl reboot

init 6

systemctl isolate runlevel3.target

init 3

Choix du niveau d'ex cution au d marrage

valeur de initdefault dans /etc/inittab

valeur du lien symbolique

default.target

En r sum :

Fonctionnalit

init (system V)

systemd

Activation d'un service

au d marrage

commande chkconfig

liens symboliques vers

/etc/init.d/

chkconfig et liens

symboliques pour les

scripts non encore migr s

commande systemctl pour

les processus pris en charge

par systemd

D marrage ou arr t

d'un service

Changement de niveau

d'ex cution

commande service

commande service ou

commande systemctl

commande init

commande init ou

commande systemctl

Vous voyez l'int r t de la nouvelle commande systemctl qui centralise toutes les

op rations mais qui permet de r aliser d'autres op rations :

• pour obtenir la liste de toutes les unit s (situ es sous /lib/systemd/system/)

et leur tat courant :

systemctl list-unit-files

• pour obtenir la liste et la description des unit s de type service :

systemctl list-units -t service

• si vous changez la configuration de systemd ou des unit s, la commande suivante

permet de faire relire les fichiers par systemd :

systemctl daemon-reload

• et si vous aimez les graphes bien touffus (et inexploitables !), vous pouvez

g n rer une image repr sentant les d pendances entre toutes les unit s par :

systemctl dor | dot -Tsvg > fichier.svg

CONCLUSION

la lecture de cet article, peut- tre avez-vous eu la r action suivante : mais

pourquoi avoir fait si compliqu alors que finalement init ne fonctionnait pas si mal

que a ? . Effectivement, je

me suis aussi pos cette question et me la pose encore. Administrateur de serveurs

Linux, je n'ai jamais connu de probl me avec init et, si parfois, on peut consid rer le

temps de d marrage comme plut t long, ce n'est rien compar aux d lais de scans et de

tests des Bios et firmwares des contr leurs de toutes sortes. Le passage vers systemd

(ou upstart) ne se justifie pas, selon moi, sur de telles plates-formes. Vouloir faire

la course entre distributions Linux, Mac OS X voire Windows (!), n'a aucun int r t

pour des serveurs. N anmoins, il semble que le pas soit pris et que, petit petit, les

principales distributions Linux nous forcent ainsi nous adapter. Alors, avant de vous

retrouver face une nouvelle version de votre Linux pr f r o init et les scripts

System V auront d finitivement disparu, tudiez d s pr sent le fonctionnement de

systemd dont le p rim tre d'action va encore s'accro tre avec la future int gration de

udev !