systemd (Français)

État de la traduction: Cet article est la version francophone de systemd. Date de la dernière traduction: 2022-05-18. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Utilisation basique de systemctl

La commande principale utilisée pour surveiller et contrôler systemd est systemctl. Certaines de ses utilisations sont l'examen de l'état du système et la gestion du système et des services. Consultez pour plus de détails.

Astuce:

Vous pouvez utiliser toutes les commandes systemctl suivantes avec le paramètre -H user@host pour contrôler une instance de systemd sur une machine distante. Ceci utilisera SSH pour se connecter à l'instance systemd distante.
Les utilisateurs de Plasma peuvent installer systemd-kcm^AUR comme interface graphique pour systemctl. Après l'installation, le module sera ajouté dans System administration.

Utilisation des unités

Les unités comprennent généralement, mais sans s'y limiter, les services (.service), les points de montage (.mount), les périphériques (.device) et les sockets (.socket).

Lorsque vous utilisez systemctl, vous devez généralement spécifier le nom complet du fichier d'unité, y compris son suffixe, par exemple sshd.socket. Il existe cependant quelques formes courtes pour spécifier l'unité dans les commandes systemctl suivantes :

Si vous ne spécifiez pas le suffixe, systemctl supposera .service. Par exemple, et sont équivalents.
Les points de montage seront automatiquement traduits dans l'unité .mount appropriée. Par exemple, spécifier est équivalent à .
De la même manière que pour les points de montage, les périphériques sont automatiquement traduits dans l'unité .device appropriée, donc spécifier est équivalent à .

Consultez pour plus de détails.

Les commandes du tableau ci-dessous opèrent sur des unités système puisque est le défaut implicite de systemctl. Pour opérer sur les unités utilisateur (pour l'utilisateur appelant), utilisez systemctl --user sans les privilèges «root». Consultez également systemd (Français)/User (Français) pour activer/désactiver les unités utilisateur pour tous les utilisateurs.

Astuce:

La plupart des commandes fonctionnent également si plusieurs unités sont spécifiées, consultez systemctl(1) pour plus d'informations.
Le paramètre --now peut être utilisé conjointement avec enable, disable et mask pour respectivement démarrer, arrêter ou masquer l'unité immédiatement plutôt qu'après le redémarrage.
Un paquet peut proposer des unités pour différents usages. Si vous venez d'installer un paquet, pacman -Qql paquet | grep -Fe .service -e .socket peut être utilisé pour les vérifier et les trouver.

Action	Commande	Note
Analyser l'état du système
Montrer l'état du système
Lister les units en cours d'exécution	ou
Lister les units en échec
Lister les fichiers d'units installés¹
Afficher l'état du processus pour un PID		cgroup slice, mémoire et parent
Vérifier l'état de l'unité
Afficher une page de manuel associée à une unité	`systemctl help unit`	tel que pris en charge par l'unité
État d'une unité		y compris si elle est en cours d'exécution ou non
Vérifier si une unité est activée
Démarrer, redémarrer, recharger d'une unité
Démarrer une unité immédiatement	en root
Arrêter une unité immédiatement	`systemctl stop unit` en root
Redémarrer une unité	en root
Recharger une unité et sa configuration	en root
Recharger la configuration du gestionnaire systemd²	en root	rechercher les unités nouvelles ou modifiées
Activer une unité
Activer une unité pour s'exécuter automatiquement au démarrage	en root
Activer une unité pour s'exécuter automatiquement au démarrage et la Démarrer immédiatement	en root
Désactiver une unité pour ne plus s'exécuter automatiquement au démarrage	en root
Réactiver une unité³	`systemctl reenable unit` en root	c'est-à-dire désactiver et réactiver
Masquer une unité
Masquer une unité pour rendre impossible son exécution⁴	en root
Démasquer une unité	en root

Consultez systemd.unit(5) § UNIT FILE LOAD PATH pour connaître les répertoires où se trouvent les fichiers d'unités disponibles.
Ceci ne demande pas aux unités modifiées de recharger leurs propres configurations (consultez l'action Recharger).
Par exemple, si sa section a été modifiée depuis sa dernière activation.
À la fois manuellement et en tant que dépendance, ce qui rend le masquage dangereux. Vérifiez si des unités masquées existent avec :

Gestion de l'énergie

Polkit est nécessaire pour la gestion de l'alimentation en tant qu'utilisateur non privilégié. Si vous êtes dans une session locale d'utilisateur systemd-logind et qu'aucune autre session n'est active, les commandes suivantes fonctionneront sans les privilèges de root. Dans le cas contraire (par exemple, parce qu'un autre utilisateur est connecté à un tty), systemd vous demandera automatiquement le mot de passe root.

Action	Commande
Arrêter et redémarrer le système
Arrêter et mettre le système hors tension
Suspendre le système
Mettre le système en hibernation
Mettre le système en état de sommeil hybride (ou suspendre à la fois)	`systemctl hybrid-sleep`

Écrire des unités

La syntaxe des fichiers «unités» de systemd () s'inspire des spécifications des fichiers .desktop XDG, qui sont à leur tour inspirés de fichiers .ini de Microsoft Windows. Les fichiers «unités» sont chargés à partir de plusieurs emplacements (pour consulter la liste complète, exécutez ), mais les principaux sont (classés de la plus basse à la plus haute priorité) :

: unités fournies par les paquets installés
/etc/systemd/system/ : unités installées par l'administrateur système

Consultez les unités installées par vos paquets pour des exemples, ainsi que .

Gérer les dépendances

Avec systemd, les dépendances peuvent être résolues en concevant correctement les fichiers d'unité. Le cas le plus typique est que l'unité A nécessite que l'unité B fonctionne avant que A ne soit lancée. Dans ce cas, ajoutez et à la section de A. Si la dépendance est facultative, ajoutez Wants=B et à la place. Notez que et n'impliquent pas , ce qui signifie que si n'est pas spécifié, les deux unités seront démarrées en parallèle.

Les dépendances sont généralement placées sur les services et non sur les #Cibles. Par exemple, est tirée par le service qui configure vos interfaces réseau, donc commander votre unité personnalisée après lui est suffisant puisque est démarrée de toute façon.

Types de service

Il existe plusieurs types de démarrage différents à considérer lors de l'écriture d'un fichier de service personnalisé. Ceci est défini avec le paramètre dans la section [Service] :

(par défaut) : systemd considère que le service doit être démarré immédiatement. Le processus ne doit pas forker. N'utilisez pas ce type si d'autres services doivent être commandés sur ce service, à moins qu'il ne soit activé par socket.
: systemd considère que le service est démarré une fois que le processus a forké et que le parent est sorti. Pour les daemons classiques, utilisez ce type sauf si vous savez que ce n'est pas nécessaire. Vous devez également spécifier pour que systemd puisse garder la trace du processus principal.
: cette option est utile pour les scripts qui effectuent une seule tâche puis se terminent. Vous pouvez également définir RemainAfterExit=yes pour que systemd considère toujours le service comme actif après la sortie du processus.
: identique à , mais avec la stipulation que le daemon enverra un signal à systemd quand il sera prêt. L'implémentation de référence pour cette notification est fournie par libsystemd-daemon.so.
: le service est considéré comme prêt lorsque le spécifié apparaît sur le bus système de DBus.
: systemd retardera l'exécution du binaire du service jusqu'à ce que tous les travaux soient distribués. A part cela, le comportement est très similaire à .

Consultez la page de manuel systemd.service(5) § OPTIONS pour une explication plus détaillée des valeurs

Modifier les unités fournies

Pour éviter les conflits avec pacman, les fichiers d'unités fournis par les paquets ne doivent pas être modifiés directement. Il existe deux façons sûres de modifier une unité sans toucher au fichier d'origine : créer un nouveau fichier d'unité qui remplace l'unité d'origine ou créer des #Fichiers de substitution qui sont appliqués par-dessus l'unité d'origine. Pour les deux méthodes, vous devez recharger l'unité après coup pour appliquer vos modifications. Vous pouvez le faire en éditant l'unité avec . (qui recharge l'unité automatiquement) ou en rechargeant toutes les unités avec :

# systemctl daemon-reload

Remplacer des fichiers d'unités

Pour remplacer le fichier d'unité , créez le fichier /etc/systemd/system/unit et réactivez l'unité pour mettre à jour les liens symboliques.

Alternativement, exécutez :

# systemctl edit --full unit

Ceci ouvre /etc/systemd/system/unit dans votre éditeur (en copiant la version installée si elle n'existe pas encore) et la recharge automatiquement lorsque vous terminez l'édition.

Fichiers de substitution

Pour créer des fichiers de substitution («drop-in files») pour le fichier d'unités , créez le répertoire et placez-y des fichiers .conf pour substituer ou ajouter de nouvelles options. systemd analysera et appliquera ces fichiers par dessus l'unité originale.

La manière la plus simple de faire est de lancer :

# systemctl edit unit.

Cela ouvre le fichier dans votre éditeur de texte (en le créant si nécessaire) et recharge automatiquement l'unité lorsque vous avez terminé l'édition.

Retour à la version d'origine

Pour rétablir les modifications apportées à une unité à l'aide de , faites :

# systemctl revert unit (unité)

Exemples

Par exemple, si vous souhaitez simplement ajouter une dépendance supplémentaire à une unité, vous pouvez créer le fichier suivant :

/etc/systemd/system/''unit''.d/customdependency.conf

[Unit]
Requires=''new dependency'' (nouvelle dépendance)
After=''new dependency'' (après la nouvelle dépendance)

Autre exemple, afin de remplacer la directive , créez le fichier suivant :

Notez comment doit être effacé avant d'être réassigné . Il en va de même pour tous les éléments qui peuvent être spécifiés plusieurs fois, par exemple pour les minuteries.

Encore un exemple pour redémarrer automatiquement un service :

Cibles

systemd utilise des cibles pour regrouper des unités via des dépendances et comme points de synchronisation standardisés. Elles ont un but similaire à celui de runlevels mais agissent un peu différemment. Chaque cible est nommée au lieu d'être numérotée et est destinée à servir un objectif spécifique avec la possibilité d'en avoir plusieurs actives en même temps. Certaines cibles sont implémentées en héritant de tous les services d'une autre cible et en lui ajoutant des services supplémentaires. Il existe des cibles systemd qui imitent les niveaux d'exécution courants de SystemVinit, vous pouvez donc toujours changer de cible en utilisant la commande familière .

Obtenir les cibles actuelles

La commande suivante doit être utilisée sous systemd au lieu d'exécuter :

$ systemctl list-units --type=target

Créer une cible personnalisée

Les runlevels qui avaient une signification définie sous sysvinit (c'est-à-dire 0, 1, 3, 5 et 6) ont une correspondance 1:1 avec une cible spécifique de systemd. Malheureusement, il n'y a pas de bon moyen de faire la même chose pour les niveaux d'exécution définis par l'utilisateur comme 2 et 4. Si vous les utilisez, il est suggéré de créer une nouvelle cible systemd nommée /etc/systemd/system/votre cible qui prend l'un des niveaux d'exécution existants comme base (vous pouvez regarder comme exemple), crée un répertoire , puis établit un lien symbolique avec les services supplémentaires de que vous souhaitez activer.

Correspondance entre les niveaux d'exécution de SysV et les cibles systemd

Niveau d'exécution SysV ! ! cible systemd ! ! Notes
0	runlevel0.target, poweroff.target	Arrêter le système.
1, s, single	runlevel1.target, rescue.target	Mode utilisateur unique.
2, 4	runlevel2.target, runlevel4.target, multi-user.target	Niveaux d'exécution définis par l'utilisateur/par site. Par défaut, identique à 3.
3	runlevel3.target, multi-user.target	Multi-utilisateur, non-graphique. Les utilisateurs peuvent généralement se connecter via plusieurs consoles ou via le réseau.
5	runlevel5.target, graphical.target	Multi-utilisateur, graphique. Offre généralement tous les services du runlevel 3 plus une connexion graphique.
6	runlevel6.target, reboot.target	Redémarrage.
emergency	emergency.target	Shell d'urgence

Changer la cible actuelle

Dans systemd, les cibles sont exposées via les target units. Vous pouvez les changer comme suit :

# systemctl isolate graphical.target

Cela ne changera que la cible actuelle, et n'aura aucun effet sur le prochain démarrage. Ceci est équivalent à des commandes telles que ou dans Sysvinit.

Changer la cible par défaut pour le démarrage

La cible standard est , qui est un lien symbolique vers graphical.target. Cela correspond à peu près à l'ancien niveau d'exécution 5.

Pour vérifier la cible actuelle avec systemctl :

$ systemctl get-default

Pour changer la cible par défaut sur laquelle démarrer, modifiez le lien symbolique . Avec systemctl :

Vous pouvez également ajouter l'un des paramètres du noyau suivants à votre chargeur d'amorçage :

(ce qui correspond à peu près à l'ancien niveau d'exécution 3),
(qui correspond en gros à l'ancien niveau d'exécution 3) (ce qui correspond à peu près à l'ancien niveau d'exécution 1).

Ordre des cibles par défaut

systemd choisit la selon l'ordre suivant :

Paramètre du noyau indiqué ci-dessus
Symlink de
Lien symbolique de /usr/lib/systemd/system/default.target

Composants de systemd

Quelques composants (non exhaustifs) de systemd sont :

systemd-boot - simple gestionnaire d'amorçage UEFI ;
systemd-firstboot - initialisation des paramètres de base du système avant le premier démarrage ;
systemd-homed - comptes utilisateurs humains portables ;
- gestion de session ;
systemd-networkd - gestion de la configuration réseau ;
systemd-nspawn - conteneurs léger ;
systemd-resolved - résolution de nom de domaine ;
- crée les utilisateurs et les groupes du système et ajoute les utilisateurs aux groupes à l'installation du paquet ou au démarrage ;
systemd-timesyncd - synchronisation du temps système à travers le réseau ;
systemd/Journal - journalisation du système ;
systemd/Timers - minuteries monotones ou en temps réel pour contrôler les fichiers .service ou les événements, alternative raisonnable à Cron.
- Un «stub» de démarrage UEFI utilisé pour créer des images de noyau unifiées.

systemd.mount - montage

systemd est chargé de monter les partitions et les systèmes de fichiers spécifiés dans . Le traduit toutes les entrées de en unités systemd ; ceci est effectué au démarrage et chaque fois que la configuration du gestionnaire de système est rechargée.

systemd étend les capacités habituelles de fstab et offre des options de montage supplémentaires. Celles-ci affectent les dépendances de l'unité de montage. Elles peuvent, par exemple, garantir qu'un montage ne sera effectué qu'une fois que le réseau sera en place ou qu'une autre partition sera montée. La liste complète des options de montage spécifiques à systemd, généralement préfixées par x-systemd., est détaillée dans .

Un exemple de ces options de montage est le montage automatique, qui signifie monter seulement lorsque la ressource est requise plutôt qu'automatiquement au démarrage. Ceci est fourni dans Fstab (Français)#Montage automatique avec systemd.

Montage automatique d'une partition GPT

Sur les systèmes amorcés par UEFI, si des conditions spécifiques sont réunies, montera automatiquement les partitions GPT conformément à la Specification de Partitions Découvrables et elles peuvent donc être omises de fstab.

Les conditions préalables sont :

Le chargeur d'amorçage doit définir la variable EFI LoaderDevicePartUUID, afin que la partition système EFI utilisée puisse être identifiée. Ceci est pris en charge par systemd-boot, et rEFInd (non activé par défaut). Cela peut être vérifié en exécutant et en vérifiant l'état de .
La partition racine doit se trouver sur le même disque physique que la partition système EFI utilisée. Les autres partitions qui seront montées automatiquement doivent se trouver sur le même disque physique que la partition racine. Cela signifie essentiellement que toutes les partitions montées automatiquement doivent partager le même disque physique avec l'ESP.

Astuce: L'automontage d'une partition peut être désactivé en modifiant le type GUID de la partition ou en définissant le bit d'attribut de la partition 63 "do not automount", consultez gdisk#Prevent GPT partition automounting.

/var

Pour que le montage automatique de fonctionne, le PARTUUID doit correspondre au hachage SHA256 HMAC de l'UUID du type de partition () avec l'ID de la machine comme clé. Le PARTUUID requis peut être obtenu en utilisant :

$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id

systemd-sysvcompat

Le rôle principal de (requis par ) est de fournir le traditionnel binaire linux init. Pour les systèmes contrôlés par systemd, init est juste un lien symbolique vers son exécutable .

En outre, il fournit quatre raccourcis pratiques auxquels les utilisateurs de SysVinit peuvent être habitués. Ces raccourcis sont , , et shutdown(8). Chacune de ces quatre commandes est un lien symbolique vers , et est régie par le comportement de systemd. Par conséquent, la discussion à #Gestion de l'énergie s'applique.

Les systèmes basés sur systemd peuvent abandonner ces méthodes de compatibilité System V en ajoutant aux paramètre de démarrage (consultez, par exemple, /bin/init est dans systemd-sysvcompat ?) et les arguments de la commande native de systemd.

systemd-tmpfiles - fichiers temporaires

systemd-tmpfiles crée, supprime et nettoie les fichiers et répertoires volatiles et temporaires. Il lit les fichiers de configuration dans et pour découvrir les actions à effectuer. Les fichiers de configuration du premier répertoire sont prioritaires sur ceux du second.

Les fichiers de configuration sont généralement fournis avec les fichiers de service, et ils sont nommés dans le style de . Par exemple, le daemon Samba s'attend à ce que le répertoire existe et ait les bonnes permissions. Par conséquent, le paquet samba est livré avec cette configuration :

Les fichiers de configuration peuvent également être utilisés pour écrire des valeurs dans certains fichiers au démarrage. Par exemple, si vous avez utilisé pour désactiver le réveil à partir de périphériques USB avec , vous pouvez utiliser le fichier tmp suivant à la place :

Consultez les pages de manuel systemd-tmpfiles(8) et pour plus de détails.

Trucs et astuces

Outils de configuration de l'interface graphique

}}

Exécution des services après le démarrage du réseau

Pour retarder un service jusqu'à ce que le réseau soit en place, incluez les dépendances suivantes dans le fichier .service :

Le service d'attente réseau de l'application particulière qui gère le réseau doit également être activé pour que network-online.target reflète correctement l'état du réseau.

Si vous utilisez NetworkManager, est activé en même temps que . Vérifiez si c'est le cas avec S'il n'est pas activé, alors réactivez .
Dans le cas de netctl, activez .
Si vous utilisez systemd-networkd, est activé en même temps que systemd-networkd.service. Vérifiez si c'est le cas avec . S'il n'est pas activé, alors réactivez systemd-networkd.service.

Pour des explications plus détaillées, voir la discussion dans Network configuration synchronization points.

Si un service doit effectuer des requêtes DNS, il doit en outre être ordonnancé après :

Consultez .

Pour que ait un quelconque effet, il faut un service qui l'attire via Wants=nss-lookup.target et qui se place avant lui avec . Cette opération est généralement effectuée par des résolveurs DNSs locaux.

Vérifiez quel service actif, s'il y en a un, tire dans avec :

$ systemctl list-dependencies --reverse nss-lookup.target

Activer les unités installées par défaut

Arch Linux est livré avec contenant . Ceci amène systemctl preset à désactiver toutes les unités par défaut, de sorte que lorsqu'un nouveau paquet est installé, l'utilisateur doit activer manuellement l'unité.

Si ce comportement n'est pas souhaité, créez simplement un lien symbolique de vers afin de remplacer le fichier de configuration. Ainsi, systemctl preset activera toutes les unités installées, quel que soit le type d'unité, à moins que cela ne soit spécifié dans un autre fichier dans l'un des répertoires de configuration de systemctl preset. Les unités utilisateur ne sont pas affectées. Consultez pour plus d'informations.

Note: L'activation de toutes les unités par défaut peut causer des problèmes avec les paquets qui contiennent deux ou plusieurs unités mutuellement exclusives. systemctl preset est conçu pour être utilisé par les distributions et les spins ou les administrateurs système. Dans le cas où deux unités conflictuelles seraient activées, vous devriez explicitement spécifier laquelle doit être désactivée dans un fichier de configuration de preset comme spécifié dans la page de manuel systemd.preset(5).

Mise en sandbox (bac à sable) des environnements d'application

Un fichier d'unité peut être créé comme un bac à sable pour isoler les applications et leurs processus dans un environnement virtuel durci. systemd utilise namespaces, une liste de capacités autorisées/refusées, et les groupes de contrôle pour conteneuriser les processus à travers une configuration étendue de l'environnement d'exécution-.

L'amélioration d'un fichier d'unité systemd existant avec le sandboxing des applications nécessite généralement des essais et des erreurs accompagnés d'une utilisation généreuse de , stderr et . Vous pouvez d'abord rechercher dans la documentation en amont des tests déjà effectués sur lesquels baser vos essais. Pour obtenir un point de départ pour les options de durcissement possibles, exécutez

$ systemd-analyze security unit (unité)

Quelques exemples de la façon dont le sandboxing avec systemd peut être déployé :

définit une liste de capabilities(7) qui sont autorisées ou refusées pour une unité. Consultez .
- La capacité , par exemple, qui devrait être l'un des objectifs d'un bac à sable sécurisé : .

Notification de l'échec d'un service

Afin de notifier les échecs de service, une directive doit être ajoutée au fichier de service correspondant, par exemple en utilisant un #Fichiers de substitution. L'ajout de cette directive à chaque unité de service peut être réalisé à l'aide d'un fichier de configuration drop-in de haut niveau. Pour plus de détails sur les fichiers de dépôt de haut niveau, consultez .

Créez un fichier de dépôt de premier niveau pour les services :

/etc/systemd/system/service.d/toplevel-override.conf

[Unit]
OnFailure=failure-notification@%n

Ceci ajoute à chaque fichier de service. Si une unité_service échoue, sera lancée pour gérer la livraison de la notification (ou toute autre tâche pour laquelle elle est configurée).

Créez l'unité de modèle :

Vous pouvez créer le script failure-notification.sh et définir ce qu'il faut faire ou comment notifier (mail, gotify, xmpp, etc.). Le sera le nom de l'unité de service défaillante et sera passé comme argument au script.

Afin d'éviter la récurrence du démarrage des instances de en cas d'échec du démarrage, créez un fichier de configuration de dépôt vide portant le même nom que le dépôt de niveau supérieur (le fichier de configuration de dépôt de niveau service vide est prioritaire sur le dépôt de niveau supérieur et remplace ce dernier) :

# mkdir -p /etc/systemd/system/failure-notification@.service.d # touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

Dépannage

Recherche des services ayant échoué

Pour trouver les services systemd qui n'ont pas réussi à démarrer :

$ systemctl --state=failed

Pour savoir pourquoi ils ont échoué, examinez leur sortie de journal. Consultez systemd/Journal#Filtering output pour plus de détails.

Diagnostic des problèmes de démarrage

systemd a plusieurs options pour diagnostiquer les problèmes avec le processus de démarrage. Consultez General troubleshooting (Français)#Problèmes de démarrage pour des instructions plus générales et des options pour capturer les messages de démarrage avant que systemd ne prenne en charge le processus de démarrage. Consultez également la documentation sur le débogage de systemd de freedesktop.org .

Diagnostic d'un service

Si un service systemd se comporte mal ou si vous souhaitez obtenir plus d'informations sur ce qui se passe, définissez la {[variable d'environnement]] à . [à . Par exemple, pour exécuter le daemon systemd-networkd en mode débogage :

Ajoutez un #Fichiers de substitution pour le service en ajoutant les deux lignes :

[Service] Environment=SYSTEMD_LOG_LEVEL=debug

Ou comme équivalent, définissez la variable d'environnement manuellement :

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

puis redémarrer systemd-networkd et regarder le journal du service avec l'option /.

L'arrêt/le redémarrage prend très longtemps

Si le processus d'arrêt prend beaucoup de temps (ou semble se figer), il est probable qu'un service qui ne se termine pas est à blâmer. systemd attend un certain temps que chaque service se termine avant d'essayer de le tuer. Pour savoir si vous êtes concerné, consultez l’extinction finit par se terminer dans le wiki systemd.

Un problème courant est un processus d'arrêt ou de suspension bloqué. Pour vérifier si c'est le cas, vous pouvez exécuter l'une ou l'autre de ces commandes et vérifier les sorties

La solution à ce problème serait d'annuler ces tâches en exécutant

# systemctl cancel # systemctl stop systemd-suspend.service

puis de réessayer l'arrêt ou le redémarrage.

Les processus à courte durée de vie ne semblent pas alimenter le journal

Si l'exécution de journalctl -u foounit en tant que root ne montre aucune sortie pour un service de courte durée, regardez plutôt le PID. Par exemple, si systemd-modules-load.service échoue et que indique qu'il a été exécuté sous le PID 123, vous pouvez consulter la sortie dans le journal pour ce PID, c'est-à-dire en exécutant en tant que root. Les champs de métadonnées du journal tels que et sont collectés de manière asynchrone et dépendent du répertoire du processus existant. Pour résoudre ce problème, il faut corriger le noyau pour qu'il fournisse ces données via une connexion socket, comme pour . En bref, il s'agit d'un bug. Gardez à l'esprit que les services qui échouent immédiatement peuvent ne rien imprimer dans le journal, conformément à la conception de systemd.

Le temps de démarrage augmente avec le temps

Après avoir utilisé , un certain nombre d'utilisateurs ont remarqué que leur temps de démarrage avait considérablement augmenté par rapport à ce qu'il était auparavant. Après avoir utilisé systemd-analyze blame NetworkManager (Français) est signalé comme prenant un temps anormalement long pour démarrer.

Pour certains utilisateurs, le problème est dû au fait que devient trop volumineux. Ceci peut avoir d'autres impacts sur les performances, comme pour ou . En tant que telle, la solution est de supprimer tous les fichiers du dossier (idéalement en faisant une sauvegarde quelque part, au moins temporairement) et ensuite de définir une taille limite pour les fichiers du journal comme décrit dans Systemd/Journal#Journal size limit.

systemd-tmpfiles-setup.service ne démarre pas au démarrage

À partir de systemd 219, spécifie les attributs ACL pour les répertoires sous et, par conséquent, exige que la prise en charge des ACL soit activé pour le système de fichiers sur lequel le journal réside.

Consultez Access Control Lists#Enable ACL pour savoir comment activer ACL sur le système de fichiers qui abrite .

Désactiver le mode d'urgence sur la machine distante

Vous pouvez souhaiter désactiver le mode d'urgence sur une machine distante, par exemple, une machine virtuelle hébergée sur Azure ou Google Cloud. En effet, si le mode d'urgence est déclenché, la machine sera bloquée pour se connecter au réseau.

Pour le désactiver, masquez et .

Voir aussi

Wikipedia:systemd
Site web officiel
Les pages de manuel
Autres distributions
L'histoire sur le blog de Lennart, mise à jour 1, mise à jour 2, mise à jour 3, Sommaire
Debugger les Services Systemd
systemd pour les administrateurs (PDF)
Comment utiliser Systemctl pour gérer les services et unités Systemd
Gestion des sessions avec systemd-logind
Coloration syntaxique pour les fichiers systemd avec Emacs
Deux parties d'un article d'introduction dans le magazine The H Open.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.