Dans Apprendre à aimer systemd , le premier article de cette série, j'ai examiné les fonctions et l'architecture de systemd et la controverse autour de son rôle en remplacement de l'ancien programme d'initialisation SystemV et des scripts de démarrage. Dans ce deuxième article, je vais commencer à explorer les fichiers et les outils qui gèrent la séquence de démarrage de Linux. J'expliquerai la séquence de démarrage de systemd, comment changer la cible de démarrage par défaut (niveau d'exécution en termes SystemV) et comment passer manuellement à une cible différente sans passer par un redémarrage.
Je vais également examiner deux outils systemd importants. Le premier est le systemctl command, qui est le principal moyen d'interagir avec et d'envoyer des commandes à systemd. Le second est journalctl , qui donne accès aux journaux systemd qui contiennent d'énormes quantités de données d'historique du système telles que les messages du noyau et du service (à la fois des messages d'information et d'erreur).
Assurez-vous d'utiliser un système de non-production pour les tests et l'expérimentation dans cet article et les futurs articles. Votre système de test doit avoir un bureau GUI (tel que Xfce, LXDE, Gnome, KDE ou autre) installé.
J'ai écrit dans mon article précédent que je prévoyais de créer une unité systemd et de l'ajouter à la séquence de démarrage de cet article. Parce que cet article est devenu plus long que prévu, je le retiendrai pour le prochain article de cette série.
Explorer le démarrage de Linux avec systemd
En savoir plus sur les administrateurs système
- Activer le blog Sysadmin
- L'entreprise automatisée :un guide pour gérer l'informatique avec l'automatisation
- Livre électronique :Automatisation Ansible pour les administrateurs système
- Témoignages du terrain :guide de l'administrateur système sur l'automatisation informatique
- eBook :Un guide de Kubernetes pour les SRE et les administrateurs système
- Derniers articles sur l'administrateur système
Avant de pouvoir observer la séquence de démarrage, vous devez effectuer quelques opérations pour que les séquences de démarrage et de démarrage soient ouvertes et visibles. Normalement, la plupart des distributions utilisent une animation de démarrage ou un écran de démarrage pour masquer les messages détaillés qui seraient autrement affichés lors du démarrage et de l'arrêt d'un hôte Linux. C'est ce qu'on appelle l'écran de démarrage Plymouth sur les distributions basées sur Red Hat. Ces messages cachés peuvent fournir de nombreuses informations sur le démarrage et l'arrêt à un administrateur système à la recherche d'informations pour résoudre un bogue ou simplement pour en savoir plus sur la séquence de démarrage. Vous pouvez modifier cela à l'aide de la configuration GRUB (Grand Unified Boot Loader).
Le fichier de configuration GRUB principal est /boot/grub2/grub.cfg , mais comme ce fichier peut être écrasé lors de la mise à jour de la version du noyau, vous ne souhaitez pas le modifier. Au lieu de cela, modifiez le /etc/default/grub fichier, qui est utilisé pour modifier les paramètres par défaut de grub.cfg .
Commencez par regarder la version actuelle non modifiée de /etc/default/grub fichier :
[root@testvm1 ~]# cd /etc/default; cat grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=enregistré
GRUB_DISABLE_SUBMENU =true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.
lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_
testvm1/usr rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
[root@testvm1 default]#
Le chapitre 6 de la documentation GRUB contient une liste de toutes les entrées possibles dans /etc/default/grub fichier, mais je me concentre sur les éléments suivants :
- Je modifie GRUB_TIMEOUT , le nombre de secondes pour le compte à rebours du menu GRUB, de cinq à 10 pour donner un peu plus de temps pour répondre au menu GRUB avant que le compte à rebours n'atteigne zéro.
- Je supprime les deux derniers paramètres sur GRUB_CMDLINE_LINUX , qui répertorie les paramètres de ligne de commande transmis au noyau au démarrage. L'un de ces paramètres, rhgb signifie Red Hat Graphical Boot, et il affiche la petite animation de l'icône Fedora lors de l'initialisation du noyau au lieu d'afficher les messages de démarrage. L'autre, le calme paramètre, empêche l'affichage des messages de démarrage qui documentent la progression du démarrage et les erreurs qui se produisent. Je supprime les deux rhgb et silencieux car les administrateurs système ont besoin de voir ces messages. Si quelque chose ne va pas pendant le démarrage, les messages affichés à l'écran peuvent indiquer la cause du problème.
Après avoir apporté ces modifications, votre fichier GRUB ressemblera à :
[root@testvm1 default]# cat grub
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=sauvé
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.
lv=fedora_testvm1/ root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_
testvm1/usr"
GRUB_DISABLE_RECOVERY="false"
[root@testvm1 default]#
Le grub2-mkconfig programme génère le grub.cfg fichier de configuration en utilisant le contenu de /etc/default/grub fichier pour modifier certains des paramètres GRUB par défaut. Le grub2-mkconfig le programme envoie sa sortie à STDOUT . Il a un -o qui vous permet de spécifier un fichier vers lequel envoyer le flux de données, mais il est tout aussi simple d'utiliser la redirection. Exécutez la commande suivante pour mettre à jour le fichier /boot/grub2/grub.cfg fichier de configuration :
[root@testvm1 grub2]# grub2-mkconfig> /boot/grub2/grub.cfg
Génération du fichier de configuration grub ...
Image linux trouvée :/boot/vmlinuz-4.18.9- 200.fc28.x86_64
Image initrd trouvée :/boot/initramfs-4.18.9-200.fc28.x86_64.img
Image linux trouvée :/boot/vmlinuz-4.17.14-202.fc28. x86_64
Image initrd trouvée :/boot/initramfs-4.17.14-202.fc28.x86_64.img
Image linux trouvée :/boot/vmlinuz-4.16.3-301.fc28.x86_64
Image initrd trouvée :/boot/initramfs-4.16.3-301.fc28.x86_64.img
Image linux trouvée :/boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504
Image initrd trouvée :/boot/ initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img
fait
[root@testvm1 grub2]#
Redémarrez votre système de test pour afficher les messages de démarrage qui seraient autrement cachés derrière l'animation de démarrage de Plymouth. Mais que se passe-t-il si vous avez besoin d'afficher les messages de démarrage et que vous n'avez pas désactivé l'animation de démarrage Plymouth ? Ou vous l'avez fait, mais les messages sont trop rapides pour être lus ? (Ce qu'ils font.)
Il existe plusieurs options, et toutes deux impliquent des fichiers journaux et des journaux systemd, qui sont vos amis. Vous pouvez utiliser le moins commande pour afficher le contenu de /var/log/messages dossier. Ce fichier contient des messages de démarrage et de démarrage ainsi que des messages générés par le système d'exploitation lors d'un fonctionnement normal. Vous pouvez également utiliser le journalctl commande sans aucune option pour afficher le journal systemd, qui contient essentiellement les mêmes informations :
[root@testvm1 grub2]# journalctl
-- Les journaux commencent le sam 2020-01-11 21:48:08 EST, se terminent le ven 2020-04-03 08:54:30 EDT. --
11 janvier 21:48:08 noyau f31vm.both.org :Linux version 5.3.7-301.fc31.x86_64 ([email protected]) (gcc version 9.2.1 20190827 ( Red Hat 9.2.1-1) (GCC)) #1 SMP Lundi Oct>
Jan 11 21:48:08 noyau f31vm.both.org :Ligne de commande :BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3 .7-301.fc31.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/VG01-swap rd.lvm.lv=VG01/root rd>
11 janvier 21:48 :08 Noyau f31vm.both.org :x86/fpu :Prise en charge de la fonction XSAVE 0x001 : 'SSE registers'
11 janvier 21:48:08 noyau f31vm.both.org :x86/fpu :prise en charge de la fonction XSAVE 0x004 :'AVX registers'
11 janvier 21:48:08 f31vm.both. org kernel :x86/fpu :xstate_offset[2] : 576, xstate_sizes[2] : 256
11 janvier 21:48:08 noyau f31vm.both.org :x86/fpu :fonctionnalités xstate activées 0x7, la taille du contexte est 832 octets, en utilisant le format "standard".
11 janvier 21:48:08 noyau f31vm.both.org :BIOS-provide d carte RAM physique :
11 janvier 21:48:08 noyau f31vm.both.org :BIOS-e820 :[mem 0x0000000000000000-0x000000000009fbff] utilisable
11 janvier 21:48:08 f31vm.both.org noyau :BIOS-e820 :[mem 0x000000000009fc00-0x000000000009ffff] réservé
11 janvier 21:48:08 f31vm.both.org noyau :BIOS-e820 :[mem 0x00000000000f0000-0x000000000001 fff] réservé
1 fff] 48:08 noyau f31vm.both.org :BIOS-e820 :[mem 0x0000000000100000-0x00000000dffeffff] utilisable
11 janvier 21:48:08 noyau f31vm.both.org :BIOS-e820 :[mem 0x00000000dfff0000000dfff0000-0x0000dfff0000-0x0000dfff0000-0x0000dfff0000-0x0000 données
11 janvier 21:48:08 noyau f31vm.both.org :BIOS-e820 :[mem 0x00000000fec00000-0x00000000fec00fff] réservé
11 janvier 21:48:08 noyau f31vm.both.org :BIOS- e820 :[mem 0x00000000fee00000-0x00000000fee00fff] réservé
11 janvier 21:48:08 noyau f31vm.both.org :BIOS-e820 :[mem 0x00000000fffc0000-0x00000000vmffffff] réservé
21 janvier f48 :01 janvier Noyau .both.org :BIOS-e820 :[mem 0x0000000100000000-0x000000041fffffff] utilisable
Jan 11 2 1:48:08 Noyau f31vm.both.org :Protection NX (Execute Disable) :active
11 janvier 21:48:08 Noyau f31vm.both.org :SMBIOS 2.5 présent.
11 21 janvier :48:08 Noyau f31vm.both.org :DMI :innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
11 janvier 21:48:08 Noyau f31vm.both.org :Hyperviseur détecté :KVM
11 janvier 21:48:08 noyau f31vm.both.org :kvm-clock :utilisation de msrs 4b564d01 et 4b564d00
11 janvier 21:48:08 noyau f31vm.both.org :kvm-clock :cpu 0, msr 30ae01001, horloge du processeur principal
11 janvier 21:48:08 noyau f31vm.both.org :kvm-clock :utilisation d'un décalage planifié de 8250734066 cycles
11 janvier 21:48:08 noyau f31vm.both.org :clocksource :kvm-clock :mask :0xffffffffffffffff max_cycles :0x1cd42e4dffb, max_idle_ns :881590591483 ns
11 janvier 21:48:08 noyau f31vm.both.org :tsc :processeur 2 807,992 MHz détecté
11 21 janvier :48:08 noyau f31vm.both.org :e820 :mise à jour [mem 0x00000000-0x00000fff] utilisable ==> réservé
11 janvier 21:48:08 noyau f31vm.both.org :e820 :suppression [mem 0x000a000 0-0x000fffff] utilisable
J'ai tronqué ce flux de données car il peut comporter des centaines de milliers, voire des millions de lignes. (La liste des journaux sur mon poste de travail principal compte 1 188 482 lignes.) Assurez-vous d'essayer ceci sur votre système de test. S'il a fonctionné pendant un certain temps, même s'il a été redémarré plusieurs fois, d'énormes quantités de données seront affichées. Explorez ces données de journal, car elles contiennent de nombreuses informations qui peuvent être très utiles lors de l'identification des problèmes. Savoir à quoi ressemblent ces données pour un démarrage et un démarrage normaux peut vous aider à localiser les problèmes lorsqu'ils surviennent.
Je parlerai des revues systemd, le journalctl commande, et comment trier toutes ces données pour trouver ce que vous voulez plus en détail dans un futur article de cette série.
Une fois que GRUB a chargé le noyau en mémoire, il doit d'abord s'extraire de la version compressée du fichier avant de pouvoir effectuer un travail utile. Une fois que le noyau s'est extrait et a commencé à s'exécuter, il charge systemd et lui donne le contrôle.
C'est la fin du processus de démarrage. À ce stade, le noyau Linux et systemd sont en cours d'exécution mais incapables d'effectuer des tâches productives pour l'utilisateur final car rien d'autre ne s'exécute, il n'y a pas de shell pour fournir une ligne de commande, pas de processus d'arrière-plan pour gérer le réseau ou d'autres liens de communication, et rien qui permette à l'ordinateur d'effectuer une quelconque fonction productive.
Systemd peut désormais charger les unités fonctionnelles nécessaires pour amener le système à un état d'exécution cible sélectionné.
Cibles
Une cible systemd représente l'état d'exécution actuel ou souhaité d'un système Linux. Tout comme les scripts de démarrage SystemV, les cibles définissent les services qui doivent être présents pour que le système s'exécute et soit actif dans cet état. La figure 1 montre les cibles d'état d'exécution possibles d'un système Linux utilisant systemd. Comme indiqué dans le premier article de cette série et dans la page de manuel de démarrage de systemd (man bootup), d'autres cibles intermédiaires sont nécessaires pour activer divers services nécessaires. Ceux-ci peuvent inclure swap.target , timers.target , local-fs.cible , et plus. Certaines cibles (comme basic.target ) sont utilisés comme points de contrôle pour s'assurer que tous les services requis sont opérationnels avant de passer à la cible de niveau supérieur.
Sauf modification contraire au démarrage dans le menu GRUB, systemd démarre toujours le default.target . La cible par défaut file est un lien symbolique vers le véritable fichier cible. Pour un poste de travail de bureau, il s'agira généralement de graphical.target , qui équivaut au niveau d'exécution 5 dans SystemV. Pour un serveur, la valeur par défaut est plus susceptible d'être multi-user.target , qui est comme le niveau d'exécution 3 dans SystemV. La cible.d'urgence fichier est similaire au mode mono-utilisateur. Les cibles et les services sont des unités systémiques.
Le tableau suivant, que j'ai inclus dans l'article précédent de cette série, compare les cibles systemd avec les anciens niveaux d'exécution de démarrage de SystemV. Les alias cibles systemd sont fournis par systemd pour une compatibilité descendante. Les alias cibles permettent aux scripts (et aux administrateurs système) d'utiliser des commandes SystemV telles que init 3 pour changer de niveau d'exécution. Bien sûr, les commandes SystemV sont transmises à systemd pour interprétation et exécution.
| cibles systemd | Niveau d'exécution SystemV | alias cibles | Description |
| default.target | Cette cible est toujours associée à un lien symbolique vers multi-user.target ou graphical.target . systemd utilise toujours le default.target pour démarrer le système. La cible par défaut ne doit jamais être associé à halt.target , poweroff.target , ou reboot.target . | ||
| cible.graphique | 5 | runlevel5.target | Cible.multi-utilisateur avec une interface graphique |
| 4 | runlevel4.target | Inutilisé. Le niveau d'exécution 4 était identique au niveau d'exécution 3 dans le monde SystemV. Cette cible peut être créée et personnalisée pour démarrer les services locaux sans modifier la valeur par défaut multi-user.target . | |
| multi-user.target | 3 | runlevel3.target | Tous les services sont en cours d'exécution, mais uniquement l'interface de ligne de commande (CLI) |
| 2 | runlevel2.target | Multi-utilisateur, sans NFS, mais tous les autres services non graphiques en cours d'exécution | |
| rescue.target | 1 | runlevel1.target | Un système de base, y compris le montage des systèmes de fichiers avec uniquement les services les plus élémentaires en cours d'exécution et un shell de secours sur la console principale |
| urgence.cible | S | Mode mono-utilisateur :aucun service n'est en cours d'exécution ; les systèmes de fichiers ne sont pas montés. Il s'agit du niveau de fonctionnement le plus élémentaire avec uniquement un shell d'urgence exécuté sur la console principale pour que l'utilisateur puisse interagir avec le système. | |
| halter.cible | Arrête le système sans l'éteindre | ||
| reboot.target | 6 | runlevel6.target | Redémarrer |
| poweroff.target | 0 | runlevel0.target | Arrête le système et coupe l'alimentation |
Chaque cible a un ensemble de dépendances décrites dans son fichier de configuration. systemd démarre les dépendances requises, qui sont les services requis pour exécuter l'hôte Linux à un niveau de fonctionnalité spécifique. Lorsque toutes les dépendances répertoriées dans les fichiers de configuration cible sont chargées et en cours d'exécution, le système s'exécute à ce niveau cible. Si vous le souhaitez, vous pouvez consulter la séquence de démarrage de systemd et les cibles d'exécution dans le premier article de cette série, Apprendre à aimer systemd .
Exploration de la cible actuelle
De nombreuses distributions Linux installent par défaut une interface de bureau graphique afin que les systèmes installés puissent être utilisés comme postes de travail. J'installe toujours à partir d'un lecteur USB de démarrage Fedora Live avec un bureau Xfce ou LXDE. Même lorsque j'installe un serveur ou un autre type d'hôte d'infrastructure (comme ceux que j'utilise pour les routeurs et les pare-feu), j'utilise l'une de ces installations qui installe un bureau GUI.
Je pourrais installer un serveur sans bureau (et ce serait typique des centres de données), mais cela ne répond pas à mes besoins. Ce n'est pas que j'ai besoin du bureau de l'interface graphique lui-même, mais l'installation de LXDE inclut de nombreux autres outils que j'utilise qui ne figurent pas dans une installation de serveur par défaut. Cela signifie moins de travail pour moi après l'installation initiale.
Mais ce n'est pas parce que j'ai un bureau GUI que cela a du sens de l'utiliser. J'ai un KVM à 16 ports que je peux utiliser pour accéder aux interfaces KVM de la plupart de mes systèmes Linux, mais la grande majorité de mon interaction avec eux se fait via une connexion SSH à distance depuis mon poste de travail principal. Cette méthode est plus sécurisée et utilise moins de ressources système pour exécuter multi-user.target par rapport à graphical.target.
Pour commencer, vérifiez la cible par défaut pour vérifier qu'il s'agit de la graphical.target :
[root@testvm1 ~]# systemctl get-default
graphical.target
[root@testvm1 ~]#
Vérifiez maintenant la cible en cours d'exécution. Il doit être identique à la cible par défaut. Vous pouvez toujours utiliser l'ancienne méthode, qui affiche les anciens niveaux d'exécution SystemV. Notez que le niveau d'exécution précédent est à gauche ; c'est N (ce qui signifie Aucun), indiquant que le niveau d'exécution n'a pas changé depuis le démarrage de l'hôte. Le chiffre 5 indique la cible actuelle, telle que définie dans l'ancienne terminologie SystemV :
[root@testvm1 ~]# niveau d'exécution
N 5
[root@testvm1 ~]#
Notez que la page de manuel des niveaux d'exécution indique que les niveaux d'exécution sont obsolètes et fournit une table de conversion.
Vous pouvez également utiliser la méthode systemd. Il n'y a pas de réponse en une ligne ici, mais elle fournit la réponse en termes systemd :
[root@testvm1 ~]# systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
cryptset active target local. Volumes chiffrés
getty.target chargé actif actif Invites de connexion
graphical.target chargé actif actif Interface graphique
local-fs-pre.target chargé actif actif Systèmes de fichiers locaux (pré)
local-fs.target chargé actif actif Systèmes de fichiers locaux
multi-user.target chargé actif actif Système multi-utilisateur
network-online.target chargé actif actif Le réseau est en ligne
network.target chargé actif actif Réseau
nfs-client.target chargé actif actif services client NFS
nss-user-lookup.target chargé actif actif Recherches de nom d'utilisateur et de groupe
paths.target chargés actifs actifs Chemins
remote-fs-pre.target chargés actifs Systèmes de fichiers distants actifs (pré)
remote-fs.target chargés actifs actifs Systèmes de fichiers distants
rpc_pipefs.target chargés actifs actifs rpc_pipefs .Target
tranches de slices.Target chargé de tranches actives gratuites
sockets.Target sockets actifs chargés
sshd -keygen.Target chargé actif actif sshdtylegen.target
Swap.Target chargé actif actif Swap
sysinit.target chargé actif actif Initialisation du système
timers.target loaded actif actif Minuteurs
LOAD =Indique si la définition d'unité a été correctement chargée. ACTIVE =
L'état d'activation de l'unité de haut niveau, c'est-à-dire la généralisation de SUB.
SUB =L'état d'activation de l'unité de bas niveau, les valeurs dépendent du type d'unité.
21 unités chargées répertoriées. Passez --all pour voir également les unités chargées mais inactives.
Pour afficher tous les fichiers d'unité installés, utilisez 'systemctl list-unit-files'.
Cela montre toutes les cibles actuellement chargées et actives. Vous pouvez également voir le graphical.target et le multi-user.target . La multi-user.target est requis avant le graphical.target peut être chargé. Dans cet exemple, le graphical.target est actif.
Basculer vers une autre cible
Passage à la cible multi-user.target est facile :
[root@testvm1 ~]# systemctl isolate multi-user.target L'affichage devrait maintenant passer du bureau de l'interface graphique ou de l'écran de connexion à une console virtuelle. Connectez-vous et répertoriez les unités systemd actuellement actives pour vérifier que graphical.target n'est plus en cours d'exécution :
[root@testvm1 ~]# systemctl list-units --type target Assurez-vous d'utiliser le niveau d'exécution commande pour vérifier qu'elle affiche à la fois les "niveaux d'exécution" précédents et actuels :
[root@testvm1 ~]# niveau d'exécution
5 3
Modification de la cible par défaut
Maintenant, changez la cible par défaut en multi-user.target afin qu'il démarre toujours dans le multi-user.target pour une interface de ligne de commande de console plutôt qu'une interface de bureau graphique. En tant qu'utilisateur root sur votre hôte de test, accédez au répertoire dans lequel la configuration systemd est conservée et faites une liste rapide :
[root@testvm1 ~]# cd /etc/systemd/system/; ll
drwxr-xr-x. 2 root root 4096 25 avril 2018 basic.target.wants
lrwxrwxrwx. 1 root root 36 août 13 16:23 default.target -> /lib/systemd/system/graphical.target
lrwxrwxrwx. 1 racine racine 39 25 avril 2018 display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x. 2 root root 4096 25 avril 2018 getty.target.wants
drwxr-xr-x. 2 root root 4096 18 août 10:16 graphical.target.wants
drwxr-xr-x. 2 root root 4096 25 avril 2018 local-fs.target.wants
drwxr-xr-x. 2 root root 4096 30 octobre 16:54 multi-user.target.wants
[root@testvm1 system]#
J'ai raccourci cette liste pour mettre en évidence quelques éléments importants qui aideront à expliquer comment systemd gère le processus de démarrage. Vous devriez pouvoir voir la liste complète des répertoires et des liens sur votre machine virtuelle.
La cible par défaut l'entrée est un lien symbolique (symlink, soft link) vers le répertoire /lib/systemd/system/graphical.target . Listez ce répertoire pour voir ce qu'il y a d'autre :
[root@testvm1 system]# ll /lib/systemd/system/ | less Vous devriez voir des fichiers, des répertoires et d'autres liens dans cette liste, mais recherchez spécifiquement multi-user.target et graphical.target . Affichez maintenant le contenu de default.target , qui est un lien vers /lib/systemd/system/graphical.target :
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier :LGPL-2.1+
#
# Ce fichier fait partie de systemd.
#
# systemd est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier
# selon les termes de la licence publique générale limitée GNU telle que publiée par
# la Free Software Foundation ; soit la version 2.1 de la licence, soit
# (à votre choix) toute version ultérieure.
[Unité]
Description=Interface graphique
Documentation=man:systemd .special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
[root@testvm1 system]#
Ce lien vers la graphical.target Le fichier décrit toutes les conditions préalables et les exigences requises par l'interface utilisateur graphique. J'explorerai au moins certaines de ces options dans le prochain article de cette série.
Pour permettre à l'hôte de démarrer en mode multi-utilisateur, vous devez supprimer le lien existant et en créer un nouveau qui pointe vers la bonne cible. Rendez le PWD /etc/systemd/system , si ce n'est déjà fait :
[root@testvm1 system]# rm -f default.target
[root@testvm1 system]# ln -s /lib/systemd/system/multi-user.target default.target
Lister la default.target lien pour vérifier qu'il pointe vers le bon fichier :
[root@testvm1 system]# ll default.target
lrwxrwxrwx 1 root root 37 Nov 28 16:08 default.target -> /lib/systemd/system/multi-user.target
[ root@testvm1 system]#
Si votre lien ne ressemble pas exactement à celui-ci, supprimez-le et réessayez. Lister le contenu de default.target lien :
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier :LGPL-2.1+
#
# Ce fichier fait partie de systemd.
#
# systemd est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier
# selon les termes de la licence publique générale limitée GNU telle que publiée par
# la Free Software Foundation ; soit la version 2.1 de la licence, soit
# (à votre choix) toute version ultérieure.
[Unité]
Description=Système multi-utilisateurs
Documentation=man :systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes
[root@testvm1 system]#
La cible par défaut —qui est en fait un lien vers le multi-user.target à ce stade, a maintenant des exigences différentes dans l'[Unité] section. Il ne nécessite pas le gestionnaire d'affichage graphique.
Redémarrez. Votre machine virtuelle doit démarrer sur la connexion à la console pour la console virtuelle 1, qui est identifiée à l'écran comme tty1. Maintenant que vous savez comment modifier la cible par défaut, remplacez-la par graphical.target en utilisant une commande conçue à cet effet.
Tout d'abord, vérifiez la cible par défaut actuelle :
[root@testvm1 ~]# systemctl get-default
multi-user.target
[root@testvm1 ~]# systemctl set-default graphic.target
Supprimé /etc/systemd /system/default.target.
Création d'un lien symbolique /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.
[root@testvm1 ~]#Entrez la commande suivante pour accéder directement à la graphical.target et la page de connexion du gestionnaire d'affichage sans avoir à redémarrer :
[root@testvm1 system]# systemctl isolate default.targetJe ne sais pas pourquoi le terme "isolate" a été choisi pour cette sous-commande par les développeurs de systemd. Mes recherches indiquent qu'il peut s'agir d'exécuter la cible spécifiée mais "d'isoler" et de mettre fin à toutes les autres cibles qui ne sont pas nécessaires pour prendre en charge la cible. Cependant, l'effet est de basculer les cibles d'une cible d'exécution à une autre, dans ce cas, de la cible multi-utilisateur à la cible graphique. La commande ci-dessus est équivalente à l'ancienne commande init 5 dans les scripts de démarrage SystemV et le programme init.
Connectez-vous au bureau de l'interface graphique et vérifiez qu'il fonctionne comme il se doit.
Résumer
Cet article a exploré la séquence de démarrage de Linux systemd et a commencé à explorer deux outils systemd importants, systemctl et journalctl . Il expliquait également comment passer d'une cible à l'autre et changer la cible par défaut.
Le prochain article de cette série créera une nouvelle unité systemd et la configurera pour s'exécuter au démarrage. Il examinera également certaines des options de configuration qui aident à déterminer où dans la séquence une unité particulière démarrera, par exemple, une fois que la mise en réseau est opérationnelle.
Ressources
De nombreuses informations sur systemd sont disponibles sur Internet, mais la plupart sont concises, obtuses ou même trompeuses. En plus des ressources mentionnées dans cet article, les pages Web suivantes offrent des informations plus détaillées et fiables sur le démarrage de systemd.
- Le projet Fedora propose un bon guide pratique de systemd. Il contient à peu près tout ce que vous devez savoir pour configurer, gérer et entretenir un ordinateur Fedora à l'aide de systemd.
- Le projet Fedora a également une bonne feuille de triche qui renvoie les anciennes commandes SystemV à des commandes systemd comparables.
- Pour des informations techniques détaillées sur systemd et les raisons de sa création, consultez la description de systemd par Freedesktop.org.
- Linux.com's "More systemd fun" propose des informations et des conseils plus avancés sur systemd.
Il existe également une série d'articles profondément techniques pour les administrateurs système Linux par Lennart Poettering, le concepteur et développeur principal de systemd. Ces articles ont été écrits entre avril 2010 et septembre 2011, mais ils sont tout aussi pertinents aujourd'hui qu'ils l'étaient alors. Une grande partie de tout ce qui a été écrit sur systemd et son écosystème est basé sur ces articles.
- Repenser le PID 1
- systemd pour les administrateurs, partie I
- systemd pour les administrateurs, partie II
- systemd pour les administrateurs, partie III
- systemd pour les administrateurs, partie IV
- systemd pour les administrateurs, partie V
- systemd pour les administrateurs, partie VI
- systemd pour les administrateurs, partie VII
- systemd pour les administrateurs, partie VIII
- systemd pour les administrateurs, partie IX
- systemd pour les administrateurs, partie X
- systemd pour les administrateurs, partie XI