Systemd : Différence entre versions

De ArchwikiFR
m (a déplacé Systemd (Français) vers Systemd)
(Taille)
 
(92 révisions intermédiaires par 17 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
{{i18n|Systemd}}
+
[[Category:Démarrage]]
 +
[[Category:init]]
 +
[[Category:Système]]
 +
[[Category:Services]]
 +
[[category:systemd]]
 +
[[en:Systemd]]
 +
{{DISPLAYTITLE:systemd}}
 +
[http://www.freedesktop.org/wiki/Software/systemd systemd] est un gestionnaire de système / service. Il permet entre autre un démarrage en parallèle, à la demande, par activation D-Bus ou socket, un suivi des services etc.
  
{{Filename|systemd}} est un système d'init censé remplacer le vieux {{Filename|sysvinit}}. Il fournit une manière automatique de démarrer, relancer ou arrêter des services, en fonction de différents déclencheurs.
+
__TOC__
  
Ce programme est en phase de '''développement intense''' et en tant que tel, peut ne pas être adapté aux besoins de tous les jours : à utiliser avec précaution, donc.
+
{{pkg|systemd}} est installé et activé par défaut sur les nouvelles installations [http://archlinux.fr/news/systemd-est-maintenant-par-defaut-sur-de-nouvelles-installations depuis octobre 2012].
  
== Comment ça marche ==
+
== Configuration ==
Imaginons que vous soyez déconnecté du réseau. Vous pourriez avoir envie d'arrêter {{Filename|sshd}} et {{Filename|avahi}}. {{Filename|systemd}} peut le faire pour vous, et en cas de reconnexion ces services seront à nouveau disponibles. De même pour le matériel : imaginons que vous ayez une imprimante et un ''dongle'' USB Bluetooth. Inutile de laisser {{Filename|cups}} et {{Filename|bluetoothd}} en marche si ceux-ci sont déconnectés.
+
 
 +
Reportez-vous à la [[:category:configuration|catégorie configuration]] pour la configuration de votre système.
 +
 
 +
Le comportement du programme {{codeline|systemd}} quant à lui, se configure à l'aide du fichier [http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html /etc/systemd/system.conf]. Mais hormis pour des raisons de ''debug'', vous n'aurez certainement pas à y toucher.
 +
 
 +
== Commandes ==
 +
'''systemd''' fournit un large panel de commande qui vous permettent d'avoir des informations ou de modifier l'état de votre système. Sans être exhaustif, voici les plus importantes :
 +
* {{codeline|systemctl}} : contrôle '''systemd''' et gère les [[#unité|unités]].
 +
* {{codeline|journalctl}} : consultation du [[#Journalisation|journal]] de '''systemd'''.
 +
* {{codeline|loginctl}} : contrôle des sessions utilisateurs ([[systemd/logind|systemd-logind]]).
  
Il n'y a pas non plus de raison de laisser des démons comme {{Filename|sshd}} en route si personne n'est connecté à la machine : systemd peut écouter sur le port dédié à SSH, et lancer sshd si quelqu'un se connecte, l'arrêter lorsque le dernier utilisateur se déconnecte.
+
{{tip|Les [http://www.freedesktop.org/software/systemd/man/ pages de manuel] de '''systemd''' sont assez bien fournies et donnent un aperçu des commandes (pages en section 1) disponibles.}}
  
Systemd a donc 3 buts principaux :
+
== Système ==
* Lancer des services en parallèle autant que possible.
 
* Surveiller les démons (comme {{Filename|monit}})
 
* Écouter les ports et contrôler les services (comme {{Filename|(x)inetd}})
 
  
== Systemd vs. Upstart ==
+
Les actions sont envoyées en utilisant la commande {{codeline|systemctl}} :
La philosophie qui gouverne systemd diffère quelque peu de celle d'Upstart. Par exemple, lorsque D-Bus est lancé par Upstart, tout ce qui en dépend, comme NetworkManager, '''sera aussi démarré'''.
 
  
Systemd fonctionne en sens inverse. C'est lorsque NetworkManager est lancé que D-Bus sera lancé automatiquement, parce qu'il est nécesasire au fonctionnement de NetworkManager. Le lancement de D-Bus n'est pas une indication que l'on souhaite lancer NetworkManager, mais simplement que les services qui en besoin pourront l'utiliser (et peuvent donc être démarrés). Le but de systemd n'est donc pas de lancer tous les services possibles lorsqu'un événement se déclenche, mais seulement celui qui est demandé par la situation.
+
Redémarrer ou arrêter :
 +
systemctl reboot
 +
systemctl poweroff
 +
{{tip|Vous pouvez directement utiliser les commandes {{codeline|reboot}}, {{codeline|poweroff}}, qui sont des liens vers {{codeline|systemctl}}
 +
}}
  
== Installation ==
+
Mettre en veille ou en hibernation :
Falconindy a effectué un travail formidable en permettant à systemd de fonctionner dans Arch. Les paquets nécessaires sont disponibles sur [[Arch_User_Repository_(Français)|AUR]]. Il faudra d'abord installer les paquets suivants.
+
  systemctl suspend
kernel26>=2.6.36
+
  systemctl hibernate
[http://aur.archlinux.org/packages.php?ID=38950 udev-systemd]
 
  [http://aur.archlinux.org/packages.php?ID=40399 dbus-systemd]
 
  [http://aur.archlinux.org/packages.php?ID=36902 systemd-git]
 
  
Pour pouvoir lancer les services habituels à la systemd, vous aurez sûrement envie d'installer le paquets arch-units :
+
{{note|Pour configurer l'hibernation, consultez également les parties [[Mkinitcpio#Hooks|hooks]] et [[Mkinitcpio#Réveil|réveil]]. N'oubliez pas de [[Mkinitcpio#Générer l'image|refaire l'image]].}}
[http://aur.archlinux.org/packages.php?ID=40419 systemd-arch-units]
 
  
Enfin, pour essayer systems, il suffit d'ajouter l'option <code>init=/bin/systemd</code> à la ligne de commande du noyau dans [[GRUB_(Français|GRUB]].
+
== Unité ==
 +
Une [http://www.freedesktop.org/software/systemd/man/systemd.unit.html unité] représente un fichier de configuration. Entre autres, une unité peut être un [http://www.freedesktop.org/software/systemd/man/systemd.service.html service] ({{codeline|*.service}}), un [http://www.freedesktop.org/software/systemd/man/systemd.target.html target] ({{codeline|*.target}}), un [http://www.freedesktop.org/software/systemd/man/systemd.mount.html montage] ({{codeline|*.mount}}), un [http://www.freedesktop.org/software/systemd/man/systemd.socket.html socket] ({{codeline|*.socket}})…
  
== Configuration ==
+
*Liste les unités:
Les services et unités (''units'') disponibles se trouvent dans {{Filename|/lib/systemd/system}}. Vous pouvez taper :
+
systemctl
  $ systemctl start <service>
+
systemctl list-units
pour lancer un service avec systemd. Pour choisir un service à lancer automatiquement au démarrage, utilisez la commande :
+
*Démarrer, arrêter, redémarrer ou recharger une unité:
  $ systemctl enable <service>
+
systemctl start <unit>
 +
systemctl stop <unit>
 +
systemctl restart <unit>
 +
systemctl reload <unit>
 +
*Voir son statut:
 +
systemctl status <unit>
 +
*Activer, désactiver une unité au démarrage:
 +
systemctl enable <unit>
 +
systemctl disable <unit>
 +
*Lister les dépendances d'une unité:
 +
systemctl list-dependencies [<unit>]
 +
 
 +
{{note|Il faut utiliser le nom du fichier d'une unité en entier, exemple:
 +
systemctl restart avahi-daemon.service
 +
Néanmoins, certains raccourcis d'écriture sont disponibles:
 +
* sans suffixe, {{codeline|systemctl}}  présume qu'il s'agit d'un {{codeline|.service}}. Ainsi, {{codeline|dbus}} et {{codeline|dbus.service}} sont équivalents:
 +
systemctl status dbus
 +
* un point de montage est automatiquement retranscrit en l'unité {{codeline|.mount}} appropriée. Par exemple {{filename|/home}} est équivalent à {{codeline|home.mount}}:
 +
systemctl status /home
 +
* de la même manière, un périphérique est retranscrit en l'unité {{codeline|.device}} appropriée. Ainsi, {{filename|/dev/sda2}} est équivalent à {{filename|dev-sda2.device}}:
 +
systemctl status /dev/sda2
 +
}}
 +
 
 +
*Recharger la configuration des services (après modification d'une unité):
 +
systemctl daemon-reload
 +
 
 +
Les unités peuvent correspondre à des ''instances'' d'un fichier ''template'', ceci permet d'avoir un fichier de configuration pour plusieurs unités. Ces unités sont reconnaissables par le '''@''' inclus dans leur nom. Un exemple concret est le ''service'' {{codeline|dhcpcd@.service}}. Ce dernier permet d'activer le DHCP sur une interface :
 +
systemctl start dhcpcd@eth0.service
 +
 
 +
Pour activer le service au démarrage :
 +
systemctl enable dhcpcd@eth0.service
 +
 
 +
== Services ==
 +
 
 +
Un service est une unité ayant comme suffixe {{codeline|.service}}. La page [[Services]] fournit une liste non exhaustive des principaux services que vous pouvez lancer (cf. colonne ''systemd'').
 +
 
 +
== Target ==
 +
 
 +
Un ''target'' est une unité particulière, elle permet de regrouper d'autres unités. Son nom de fichier prend le suffixe {{codeline|.target}}.
 +
 
 +
Les ''targets'' permettent de fournir l'équivalent des niveaux d'exécution (runlevel) de '''sysvinit''' :
 +
 
 +
{| class="wikitable"
 +
!SystemVinit Runlevel!!Systemd Target!!Notes
 +
|-
 +
| 0 || runlevel0.target, poweroff.target || arrête le système
 +
|-
 +
| 1, s, single || runlevel1.target, rescue.target || mode ''single user''.
 +
|-
 +
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Mode défini par l'utilisateur, identique au 3 par défaut.
 +
|-
 +
| 3 || runlevel3.target, multi-user.target || Multi-utilisateur, non graphique.
 +
|-
 +
| 5 || runlevel5.target, graphical.target || Multi-utilisateur, en mode graphique.
 +
|-
 +
| 6 || runlevel6.target, reboot.target || Redémarre
 +
|-
 +
| emergency || emergency.target || Shell d'urgence
 +
|-
 +
|}
 +
 
 +
Vous pouvez voir ce que regroupe un target en lançant :
 +
systemctl show -p Wants -p Requires <target>
 +
 
 +
Par exemple, on peut voir que '''graphical''' ne fait que rajouter un [[:category:Gestionnaire de connexions|gestionnaire de connexions]] en plus de '''multi-user''' ({{codeline|systemd-update-utmp-runlevel.service}} n'étant là que pour mettre à jour le ''runlevel'') :
 +
{{command|name=systemctl --no-pager show -p Wants -p Requires graphical.target|output=
 +
Requires=multi-user.target
 +
Wants=display-manager.service systemd-update-utmp-runlevel.service
 +
}}
 +
 
 +
Pour changer de ''target'', par exemple pour passer au '''multi-user''', lancez l'une de ces commandes:
 +
systemctl isolate multi-user.target
 +
systemctl isolate runlevel3.target
 +
telinit 3
 +
 
 +
Le ''target'' par défaut à l'installation est '''graphical''' :
 +
{{command|name=readlink /usr/lib/systemd/system/default.target|output=
 +
graphical.target
 +
}}
 +
 
 +
Pour spécifier un autre niveau par défaut, par exemple le '''multi-user''' :
 +
systemctl set-default -f multi-user.target
 +
 
 +
== Diagnostic ==
 +
Vous pouvez à tout moment avoir des informations sur l'état des unités avec la commande :
 +
  systemctl status <unit>
 +
 
 +
=== Erreur au chargement ===
 +
 
 +
====Exemple: service installé mais non fonctionnel====
 +
Par défaut, le ''target'' '''graphical''' est sélectionné, ceci dit, même si un gestionnaire de connexion est installé, il ne démarre pas :
 +
{{command|name=systemctl -t service -a --full <nowiki>|</nowiki> grep error|output=
 +
display-manager.service  error  inactive dead        display-manager.service
 +
}}
 +
{{command|name=systemctl status display-manager.service|output=
 +
display-manager.service
 +
  Loaded: error (Reason: No such file or directory)
 +
  Active: inactive (dead)
 +
}}
 +
'''systemd''' ne trouve pas de {{codeline|display-manager.service}} parce qu'on ne lui en a indiqué aucun. Si vous avez installé {{pkg|slim}} par exemple :
 +
{{command|name=systemctl enable slim.service|prompt=#|output=
 +
ln -s '/usr/lib/systemd/system/slim.service' '/etc/systemd/system/display-manager.service'
 +
}}
 +
Et là :
 +
{{command|name=systemctl status display-manager.service|output=
 +
slim.service - SLiM Simple Login Manager
 +
  Loaded: loaded (/usr/lib/systemd/system/slim.service; enabled)
 +
  Active: inactive (dead)
 +
  CGroup: name=systemd:/system/slim.service
 +
}}
 +
Vous n'aurez plus qu'à le lancer :
 +
systemctl start display-manager.service
 +
 
 +
====Exemple: service non installé====
 +
 
 +
Si '''systemd''' liste des services qui se rapportent à des logiciels non-installés sur la machine, par exemple :
 +
{{command|name=systemctl -t service -a --full <nowiki>|</nowiki> grep error|output=
 +
auditd.service                error  inactive dead        auditd.service
 +
plymouth-quit-wait.service    error  inactive dead        plymouth-quit-wait.service
 +
plymouth-start.service        error  inactive dead        plymouth-start.service
 +
syslog.service                error  inactive dead        syslog.service
 +
}}
 +
Vous pouvez les masquer avec la commande suivante:
 +
  systemctl mask auditd.service plymouth-quit-wait.service plymouth-start.service syslog.service
 +
 
 +
{{important|Faites bien attention quand vous masquez ces services, car cela empêche leur activation, même manuellement. Avant de les réutiliser, vous devrez les «démasquer»:
 +
systemctl unmask auditd.service
 +
}}
 +
 
 +
=== Erreur au lancement ===
 +
{{command|name=systemctl --failed|output=
 +
UNIT                LOAD  ACTIVE SUB    JOB DESCRIPTION
 +
dhcpcd@eth0.service loaded failed failed    dhcpcd on eth0
 +
 
 +
LOAD  = Reflects whether the unit definition was properly loaded.
 +
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
 +
SUB    = The low-level unit activation state, values depend on unit type.
 +
JOB    = Pending job for the unit.
 +
 
 +
1 units listed. Pass --all to see inactive units, too.
 +
}}
 +
{{command|name=systemctl status dhcpcd@eth0.service|prompt=#|output=
 +
dhcpcd@eth0.service - dhcpcd on eth0
 +
  Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled)
 +
  Active: failed (Result: exit-code) since Tue, 31 Jul 2012 15:09:03 +0200; 2min 58s ago
 +
Process: 1251 ExecStart=/sbin/dhcpcd -A -q -w %I (code=exited, status=1/FAILURE)
 +
  CGroup: name=systemd:/system/dhcpcd@.service/eth0
 +
 
 +
Jul 31 15:09:03 archtest dhcpcd[1251]: dhcpcd already running on pid 311 (/run/dhcpcd-eth0.pid)
 +
}}
 +
Un autre '''dhcpcd''' est en cours :
 +
{{command|name=ps h -C dhcpcd -o cgroup|output=
 +
3:cpuacct,cpu:/system/wicd.service,1:name=systemd:/system/wicd.service
 +
}}
 +
C'était à des fins de tests, {{codeline|wicd.service}} était lancé.
 +
 
 +
=== Démarrage ===
 +
 
 +
Vous pouvez avoir un aperçu de ce qui est démarré et le temps que ça prend avec la commande {{codeline|systemd-analyze}}.
 +
{{note|Cette commande a besoin de {{pkg|python2-cairo}}, {{pkg|python2-gobject}} et {{pkg|python2-dbus}}, installez-les si ce n'est pas déjà le cas.}}
 +
{{command|name=systemd-analyze|output=
 +
Startup finished in 5421ms (kernel) + 11246ms (userspace) = 16668ms
 +
}}
 +
 
 +
{{command|name=systemd-analyze blame|output=
 +
  3421ms wicd.service
 +
  1278ms systemd-remount-fs.service
 +
  1154ms systemd-logind.service
 +
  1033ms systemd-vconsole-setup.service
 +
  873ms sys-kernel-debug.mount
 +
  859ms dev-hugepages.mount
 +
  845ms systemd-udevd.service
 +
  795ms dev-mqueue.mount
 +
  502ms console-kit-daemon.service
 +
  380ms systemd-udev-trigger.service
 +
  339ms upower.service
 +
  251ms systemd-tmpfiles-setup.service
 +
  235ms systemd-user-sessions.service
 +
  232ms systemd-sysctl.service
 +
  187ms udisks2.service
 +
  117ms home.mount
 +
  112ms console-kit-log-system-start.service
 +
    5ms tmp.mount
 +
    3ms sys-fs-fuse-connections.mount
 +
}}
 +
 
 +
Ou encore, un aperçu graphique :
 +
systemd-analyze plot > plot.svg
 +
 
 +
=== Montage ===
 +
 
 +
Si vous avez des périphériques non forcément connectés lors du démarrage et que vous les spécifiez dans {{filename|/etc/fstab}}, n'oubliez pas de rajouter l'option {{codeline|nofail}} pour ne pas vous retrouver avec un démarrage bloqué.
 +
{{note|L'option {{codeline|nofail}} n'est pas valable pour les types dépendant de ''fuse'' (''ntfs-3g'', ''cifs'', etc.) et les partitions sur le réseau sont gérées différemment, '''systemd''' peut démarrer sans.}}
 +
'''systemd''' a un ''timeout'' de '''90 secondes''' par défaut, ce n'est qu'après ce temps qu'il vous informe d'un échec :
 +
[ TIME ] Timed out waiting for device dev-sdb1.device
 +
[DEPEND] Dependency failed for /media/disque_usb_1
 +
et vous donne la main :
 +
Welcome to emergency mode. Use "systemctl default" or ^D to enter default mode.
 +
Give root password for maintenance
 +
(or type Control-D to continue):
 +
{{important|Le {{keypress|Ctrl}}-{{keypress|D}} ou le {{codeline|systemctl default}} reprendra là où '''systemd''' s'est arrêté. Si vous n'avez fait aucun changement, vous allez repartir pour 90s d'attente.}}
 +
 
 +
Pour remédier temporairement au souci, vous pouvez éventuellement utiliser le shell d'urgence (celui que vous aurez une fois le mot de passe '''root''' entré) :
 +
systemctl mask media-disque_usb_1.mount
 +
# ne pas oublier de le 'unmask' une fois le souci réglé
 +
systemctl default
 +
Le démarrage devrait continuer. Mais pour une solution plus pérenne, modifiez la ligne concernant ce périphérique dans le {{filename|/etc/fstab}} en rajoutant {{codeline|nofail}}:
 +
/dev/sdb1 /media/disque__usb_1 auto defaults,nofail 0 0
 +
 
 +
== Journalisation ==
 +
'''systemd''' possède son propre mécanisme de journalisation, '''syslog''' n'est plus requis par défaut.
 +
=== Visualiser ===
 +
{{important|Seul le {{codeline|root}} et le groupe {{codeline|systemd-journal}} peuvent visualiser le journal.}}
 +
 
 +
Pour accéder au log :
 +
journalctl
 +
# ou si vous voulez les messages d'un seul service
 +
journalctl -u wicd
 +
# ou alors par PID
 +
journalctl _PID=1
 +
# ou même par exécutable
 +
journalctl /usr/sbin/dhcpcd
 +
Vous pouvez aussi accéder au log récent d'une unité spécifique par le biais de {{codeline|systemctl status}} :
 +
  systemctl status wicd.service
 +
 
 +
Ou obtenir les logs depuis ou jusqu'à une date précise, à l'aide respectivement de {{codeline|--since}} ou {{codeline|--until}}:
 +
#journal du jour:
 +
journalctl --since="today"
 +
#jusqu'à une date donnée (par exemple au 20 février 2013, 12h30):
 +
journalctl --until="2013-02-20 12:30:00"
 +
#ou dans un intervalle précis (par exemple le 15 mars 2013 entre 13h et 13h10min30s):
 +
journalctl --since="2013-03-15 13:00:00" --until="2013-03-15 13:10:30"
 +
 
 +
'''journalctl''' permet aussi de filtrer par le niveau de log (tel que défini par syslog). Pour n'afficher que les erreurs :
 +
journalctl -p err
  
== Remplacer les scripts d'init par défaut (DANGEREUX) ==
+
Vous pouvez voir les pages de manuel de [http://www.freedesktop.org/software/systemd/man/journalctl.html journalctl] et [http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html systemd.journal-fields] pour plus d'informations.
Pour aller plus loin, il est possible de remplacer les scripts d'init par défaut d'ArchLinux par des scripts mieux adaptés à systemd '''à vos risques et périls'''. Ces scripts se trouvent sur AUR. Cependant, pour revenir à la procédure de démarrage habituelle, il ne suffira plus de retirer l'option <code>init=/bin/systemd</code> de la ligne de commande du noyau, '''ceci casserait votre système''' puisqu'il faudrait au préalable réinstaller les initscripts par défaut. En particulier, si quelque chose ne fonctionne plus dans systemd, il est probable que le système ne démarrera plus et il faudra un LiveCD pour le restaurer.
 
  
'''Si vous êtes toujours sûr de ce que vous voulez faire''', il s'agit de ce paquet :
+
=== Taille ===
[http://aur.archlinux.org/packages.php?ID=40592 initscripts-systemd-git]
+
Vous pouvez limiter la taille maximum du journal (par défaut à 10% de la taille du système de fichier). Pour la fixer à 50 Mio par exemple :
 +
{{file|name=/etc/systemd/journald.conf|content=[Journal]
 +
SystemMaxUse=50M}}
  
== Problèmes connus ==
+
En fixant une limite par fichier, vous aurez un équivalent de [[Cron#Archivage_des_logs|'''logrotate''']] (par défaut, il garde 7 rotations):
* Systemd ne comprend pas les guillemets dans les <code>EnvironmentFiles</code>, et les services correspondants ne pourront pas démarrer. Un bon exemple est le fichier {{Filename|/etc/conf.d/sshd}} par défaut.
+
{{file|name=/etc/systemd/journald.conf|content=[Journal]
 +
SystemMaxUse=50M
 +
SystemMaxFileSize=10M}}
  
== Donner un coup de main ==
+
Si vous ne voulez pas avoir un journal persistent, vous pouvez tout simplement ne pas le stocker sur le disque :
Pour le moment, l'implémentation de systemd pour ArchLinux est encore très incomplète. Si vous voulez contribuer, vous pouvez ''forker'' les dépôts Git [http://github.com/falconindy/initscripts-systemd initscripts-systemd] ou [http://github.com/falconindy/systemd-arch-units arch-systemd-units] (sur GitHub) et proposer des ''pull requests'' pour vos modifications. Il y a encore pas mal de travail à faire pour nettoyer les initscripts et remplacer plus de fonctions par des unités systemd, de même qu'il faut encore convertir les scripts de lancement de démons en fichiers de service dépendant moins de scripts shell.
+
{{file|name=/etc/systemd/journald.conf|content=<nowiki>[Journal]
 +
Storage=volatile
 +
</nowiki>}}
  
Vous pouvez poser vos questions (en anglais) dans ce [https://bbs.archlinux.org/viewtopic.php?id=96316&p=1 sujet] sur les forums ArchLinux. falconindy peut parfois être présent sur le canal IRC #archlinux (pas de messages privés svp).
+
=== syslog ===
 +
Si vous voulez avoir '''syslog''' en parallèle avec '''journald''' (pour avoir des fichiers texte par exemple), il suffit d'installer {{pkg|syslog-ng}}, puis de l'activer :
 +
systemctl enable syslog-ng.service
  
== Ressources supplémentaires (en anglais) ==
+
== Autres ==
* [http://0pointer.de/blog/projects/systemd.html Lennart Poettering on systemd]
 
* [http://blog.falconindy.com/articles/systemd-on-arch.html falconindy's article on systemd in Arch]
 
* [https://bbs.archlinux.org/viewtopic.php?id=96316&p=1 The systemd thread on the Arch forums]
 
* [http://aur.archlinux.org/packages.php?K=falconindy&SeB=m falconindy's packages on AUR]
 
  
[[Catégorie:Démarrage]]
+
* {{codeline|systemadm}}: une interface graphique pour contrôler '''systemd''' disponible à {{pkg|systemd-ui}}  (elle est encore loin d'être terminée, à utiliser à vos risques et périls.)
[[Catégorie:Howto]]
+
* [[systemd/logind|logind]] : gestionnaire de sessions utilisateurs.
 +
* [[Systemd/cron|systemd/cron]] : réaliser des tâches planifiées.
 +
* [[Systemd/utilisateur|systemd/utilisateur]] : emploi dans l'espace utilisateur.

Version actuelle datée du 3 février 2018 à 01:47


systemd est un gestionnaire de système / service. Il permet entre autre un démarrage en parallèle, à la demande, par activation D-Bus ou socket, un suivi des services etc.

systemd est installé et activé par défaut sur les nouvelles installations depuis octobre 2012.

Configuration

Reportez-vous à la catégorie configuration pour la configuration de votre système.

Le comportement du programme systemd quant à lui, se configure à l'aide du fichier /etc/systemd/system.conf. Mais hormis pour des raisons de debug, vous n'aurez certainement pas à y toucher.

Commandes

systemd fournit un large panel de commande qui vous permettent d'avoir des informations ou de modifier l'état de votre système. Sans être exhaustif, voici les plus importantes :

  • systemctl : contrôle systemd et gère les unités.
  • journalctl : consultation du journal de systemd.
  • loginctl : contrôle des sessions utilisateurs (systemd-logind).
Astuce : Les pages de manuel de systemd sont assez bien fournies et donnent un aperçu des commandes (pages en section 1) disponibles.

Système

Les actions sont envoyées en utilisant la commande systemctl :

Redémarrer ou arrêter :

systemctl reboot
systemctl poweroff
Astuce : Vous pouvez directement utiliser les commandes reboot, poweroff, … qui sont des liens vers systemctl

Mettre en veille ou en hibernation :

systemctl suspend
systemctl hibernate
Note : Pour configurer l'hibernation, consultez également les parties hooks et réveil. N'oubliez pas de refaire l'image.

Unité

Une unité représente un fichier de configuration. Entre autres, une unité peut être un service (*.service), un target (*.target), un montage (*.mount), un socket (*.socket)…

  • Liste les unités:
systemctl
systemctl list-units
  • Démarrer, arrêter, redémarrer ou recharger une unité:
systemctl start <unit>
systemctl stop <unit>
systemctl restart <unit>
systemctl reload <unit>
  • Voir son statut:
systemctl status <unit>
  • Activer, désactiver une unité au démarrage:
systemctl enable <unit>
systemctl disable <unit>
  • Lister les dépendances d'une unité:
systemctl list-dependencies [<unit>]
Note : Il faut utiliser le nom du fichier d'une unité en entier, exemple:
systemctl restart avahi-daemon.service

Néanmoins, certains raccourcis d'écriture sont disponibles:

  • sans suffixe, systemctl présume qu'il s'agit d'un .service. Ainsi, dbus et dbus.service sont équivalents:
systemctl status dbus
  • un point de montage est automatiquement retranscrit en l'unité .mount appropriée. Par exemple /home est équivalent à home.mount:
systemctl status /home
  • de la même manière, un périphérique est retranscrit en l'unité .device appropriée. Ainsi, /dev/sda2 est équivalent à dev-sda2.device:
systemctl status /dev/sda2
  • Recharger la configuration des services (après modification d'une unité):
systemctl daemon-reload

Les unités peuvent correspondre à des instances d'un fichier template, ceci permet d'avoir un fichier de configuration pour plusieurs unités. Ces unités sont reconnaissables par le @ inclus dans leur nom. Un exemple concret est le service dhcpcd@.service. Ce dernier permet d'activer le DHCP sur une interface :

systemctl start dhcpcd@eth0.service

Pour activer le service au démarrage :

systemctl enable dhcpcd@eth0.service

Services

Un service est une unité ayant comme suffixe .service. La page Services fournit une liste non exhaustive des principaux services que vous pouvez lancer (cf. colonne systemd).

Target

Un target est une unité particulière, elle permet de regrouper d'autres unités. Son nom de fichier prend le suffixe .target.

Les targets permettent de fournir l'équivalent des niveaux d'exécution (runlevel) de sysvinit :

SystemVinit Runlevel Systemd Target Notes
0 runlevel0.target, poweroff.target arrête le système
1, s, single runlevel1.target, rescue.target mode single user.
2, 4 runlevel2.target, runlevel4.target, multi-user.target Mode défini par l'utilisateur, identique au 3 par défaut.
3 runlevel3.target, multi-user.target Multi-utilisateur, non graphique.
5 runlevel5.target, graphical.target Multi-utilisateur, en mode graphique.
6 runlevel6.target, reboot.target Redémarre
emergency emergency.target Shell d'urgence

Vous pouvez voir ce que regroupe un target en lançant :

systemctl show -p Wants -p Requires <target>

Par exemple, on peut voir que graphical ne fait que rajouter un gestionnaire de connexions en plus de multi-user (systemd-update-utmp-runlevel.service n'étant là que pour mettre à jour le runlevel) :

$ systemctl --no-pager show -p Wants -p Requires graphical.target
Requires=multi-user.target
Wants=display-manager.service systemd-update-utmp-runlevel.service

Pour changer de target, par exemple pour passer au multi-user, lancez l'une de ces commandes:

systemctl isolate multi-user.target
systemctl isolate runlevel3.target
telinit 3

Le target par défaut à l'installation est graphical :

$ readlink /usr/lib/systemd/system/default.target
graphical.target

Pour spécifier un autre niveau par défaut, par exemple le multi-user :

systemctl set-default -f multi-user.target

Diagnostic

Vous pouvez à tout moment avoir des informations sur l'état des unités avec la commande :

systemctl status <unit>

Erreur au chargement

Exemple: service installé mais non fonctionnel

Par défaut, le target graphical est sélectionné, ceci dit, même si un gestionnaire de connexion est installé, il ne démarre pas :

$ systemctl -t service -a --full | grep error
display-manager.service   error  inactive dead        display-manager.service
$ systemctl status display-manager.service
display-manager.service
	  Loaded: error (Reason: No such file or directory)
	  Active: inactive (dead)

systemd ne trouve pas de display-manager.service parce qu'on ne lui en a indiqué aucun. Si vous avez installé slim par exemple :

# systemctl enable slim.service
ln -s '/usr/lib/systemd/system/slim.service' '/etc/systemd/system/display-manager.service'

Et là :

$ systemctl status display-manager.service
slim.service - SLiM Simple Login Manager
	  Loaded: loaded (/usr/lib/systemd/system/slim.service; enabled)
	  Active: inactive (dead)
	  CGroup: name=systemd:/system/slim.service

Vous n'aurez plus qu'à le lancer :

systemctl start display-manager.service

Exemple: service non installé

Si systemd liste des services qui se rapportent à des logiciels non-installés sur la machine, par exemple :

$ systemctl -t service -a --full | grep error
auditd.service                 error  inactive dead        auditd.service
plymouth-quit-wait.service     error  inactive dead        plymouth-quit-wait.service
plymouth-start.service         error  inactive dead        plymouth-start.service
syslog.service                 error  inactive dead        syslog.service

Vous pouvez les masquer avec la commande suivante:

 systemctl mask auditd.service plymouth-quit-wait.service plymouth-start.service syslog.service
Important : Faites bien attention quand vous masquez ces services, car cela empêche leur activation, même manuellement. Avant de les réutiliser, vous devrez les «démasquer»:
systemctl unmask auditd.service

Erreur au lancement

$ systemctl --failed
UNIT                LOAD   ACTIVE SUB    JOB DESCRIPTION
dhcpcd@eth0.service loaded failed failed     dhcpcd on eth0

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
JOB    = Pending job for the unit.

1 units listed. Pass --all to see inactive units, too.
# systemctl status dhcpcd@eth0.service
dhcpcd@eth0.service - dhcpcd on eth0
	  Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled)
	  Active: failed (Result: exit-code) since Tue, 31 Jul 2012 15:09:03 +0200; 2min 58s ago
	 Process: 1251 ExecStart=/sbin/dhcpcd -A -q -w %I (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/dhcpcd@.service/eth0

Jul 31 15:09:03 archtest dhcpcd[1251]: dhcpcd already running on pid 311 (/run/dhcpcd-eth0.pid)

Un autre dhcpcd est en cours :

$ ps h -C dhcpcd -o cgroup
3:cpuacct,cpu:/system/wicd.service,1:name=systemd:/system/wicd.service

C'était à des fins de tests, wicd.service était lancé.

Démarrage

Vous pouvez avoir un aperçu de ce qui est démarré et le temps que ça prend avec la commande systemd-analyze.

Note : Cette commande a besoin de python2-cairo, python2-gobject et python2-dbus, installez-les si ce n'est pas déjà le cas.
$ systemd-analyze
Startup finished in 5421ms (kernel) + 11246ms (userspace) = 16668ms
$ systemd-analyze blame
3421ms wicd.service
  1278ms systemd-remount-fs.service
  1154ms systemd-logind.service
  1033ms systemd-vconsole-setup.service
   873ms sys-kernel-debug.mount
   859ms dev-hugepages.mount
   845ms systemd-udevd.service
   795ms dev-mqueue.mount
   502ms console-kit-daemon.service
   380ms systemd-udev-trigger.service
   339ms upower.service
   251ms systemd-tmpfiles-setup.service
   235ms systemd-user-sessions.service
   232ms systemd-sysctl.service
   187ms udisks2.service
   117ms home.mount
   112ms console-kit-log-system-start.service
     5ms tmp.mount
     3ms sys-fs-fuse-connections.mount

Ou encore, un aperçu graphique :

systemd-analyze plot > plot.svg

Montage

Si vous avez des périphériques non forcément connectés lors du démarrage et que vous les spécifiez dans /etc/fstab, n'oubliez pas de rajouter l'option nofail pour ne pas vous retrouver avec un démarrage bloqué.

Note : L'option nofail n'est pas valable pour les types dépendant de fuse (ntfs-3g, cifs, etc.) et les partitions sur le réseau sont gérées différemment, systemd peut démarrer sans.

systemd a un timeout de 90 secondes par défaut, ce n'est qu'après ce temps qu'il vous informe d'un échec :

[ TIME ] Timed out waiting for device dev-sdb1.device
[DEPEND] Dependency failed for /media/disque_usb_1

et vous donne la main :

Welcome to emergency mode. Use "systemctl default" or ^D to enter default mode.
Give root password for maintenance
(or type Control-D to continue):
Important : Le Ctrl-D ou le systemctl default reprendra là où systemd s'est arrêté. Si vous n'avez fait aucun changement, vous allez repartir pour 90s d'attente.

Pour remédier temporairement au souci, vous pouvez éventuellement utiliser le shell d'urgence (celui que vous aurez une fois le mot de passe root entré) :

systemctl mask media-disque_usb_1.mount
# ne pas oublier de le 'unmask' une fois le souci réglé
systemctl default

Le démarrage devrait continuer. Mais pour une solution plus pérenne, modifiez la ligne concernant ce périphérique dans le /etc/fstab en rajoutant nofail:

/dev/sdb1 /media/disque__usb_1 auto defaults,nofail 0 0

Journalisation

systemd possède son propre mécanisme de journalisation, syslog n'est plus requis par défaut.

Visualiser

Important : Seul le root et le groupe systemd-journal peuvent visualiser le journal.

Pour accéder au log :

journalctl
# ou si vous voulez les messages d'un seul service
journalctl -u wicd
# ou alors par PID
journalctl _PID=1
# ou même par exécutable
journalctl /usr/sbin/dhcpcd

Vous pouvez aussi accéder au log récent d'une unité spécifique par le biais de systemctl status :

systemctl status wicd.service

Ou obtenir les logs depuis ou jusqu'à une date précise, à l'aide respectivement de --since ou --until:

#journal du jour:
journalctl --since="today"
#jusqu'à une date donnée (par exemple au 20 février 2013, 12h30):
journalctl --until="2013-02-20 12:30:00"
#ou dans un intervalle précis (par exemple le 15 mars 2013 entre 13h et 13h10min30s):
journalctl --since="2013-03-15 13:00:00" --until="2013-03-15 13:10:30"

journalctl permet aussi de filtrer par le niveau de log (tel que défini par syslog). Pour n'afficher que les erreurs :

journalctl -p err

Vous pouvez voir les pages de manuel de journalctl et systemd.journal-fields pour plus d'informations.

Taille

Vous pouvez limiter la taille maximum du journal (par défaut à 10% de la taille du système de fichier). Pour la fixer à 50 Mio par exemple :

Fichier: /etc/systemd/journald.conf
[Journal]
SystemMaxUse=50M

En fixant une limite par fichier, vous aurez un équivalent de logrotate (par défaut, il garde 7 rotations):

Fichier: /etc/systemd/journald.conf
[Journal]
SystemMaxUse=50M
SystemMaxFileSize=10M

Si vous ne voulez pas avoir un journal persistent, vous pouvez tout simplement ne pas le stocker sur le disque :

Fichier: /etc/systemd/journald.conf
[Journal]
Storage=volatile

syslog

Si vous voulez avoir syslog en parallèle avec journald (pour avoir des fichiers texte par exemple), il suffit d'installer syslog-ng, puis de l'activer :

systemctl enable syslog-ng.service

Autres

  • systemadm: une interface graphique pour contrôler systemd disponible à systemd-ui (elle est encore loin d'être terminée, à utiliser à vos risques et périls.)
  • logind : gestionnaire de sessions utilisateurs.
  • systemd/cron : réaliser des tâches planifiées.
  • systemd/utilisateur : emploi dans l'espace utilisateur.