Dans les deux premiers articles de cette série, j'ai exploré la séquence de démarrage Linux systemd. Dans le premier article, 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. Et dans le deuxième article, j'ai examiné deux outils systemd importants, systemctl et journalctl, et j'ai expliqué comment passer d'une cible à une autre et changer la cible par défaut.
Dans ce troisième article, j'examinerai plus en détail les unités systemd et comment utiliser la commande systemctl pour explorer et gérer les unités. J'expliquerai également comment arrêter et désactiver des unités et comment créer une nouvelle unité de montage systemd pour monter un nouveau système de fichiers et lui permettre de démarrer au démarrage.
Préparation
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
Toutes les expériences de cet article doivent être effectuées en tant qu'utilisateur root (sauf indication contraire). Certaines des commandes qui répertorient simplement diverses unités systemd peuvent être exécutées par des utilisateurs non root, mais les commandes qui apportent des modifications ne le peuvent pas. Assurez-vous d'effectuer tous ces tests uniquement sur des hôtes hors production ou des machines virtuelles (VM).
L'une de ces expériences nécessite le package sysstat, installez-le donc avant de continuer. Pour Fedora et les autres distributions basées sur Red Hat, vous pouvez installer sysstat avec :
dnf -y install sysstatLe RPM sysstat installe plusieurs outils statistiques qui peuvent être utilisés pour l'identification des problèmes. L'un est le rapport d'activité du système (SAR), qui enregistre de nombreux points de données de performances du système à intervalles réguliers (toutes les 10 minutes par défaut). Plutôt que de s'exécuter en tant que démon en arrière-plan, le package sysstat installe deux minuteries systemd. Une minuterie s'exécute toutes les 10 minutes pour collecter des données, et l'autre s'exécute une fois par jour pour agréger les données quotidiennes. Dans cet article, j'examinerai brièvement ces minuteurs, mais attendons d'expliquer comment créer un minuteur dans un prochain article.
suite systemd
Le fait est que systemd est plus qu'un simple programme. Il s'agit d'une vaste suite de programmes tous conçus pour fonctionner ensemble afin de gérer presque tous les aspects d'un système Linux en cours d'exécution. Une exposition complète de systemd prendrait un livre à elle seule. La plupart d'entre nous n'ont pas besoin de comprendre tous les détails sur la façon dont tous les composants de systemd s'emboîtent, je vais donc me concentrer sur les programmes et les composants qui vous permettent de gérer divers services Linux et de gérer les fichiers journaux et les journaux.
Structure pratique
La structure de systemd - en dehors de ses fichiers exécutables - est contenue dans ses nombreux fichiers de configuration. Bien que ces fichiers aient des noms et des extensions d'identifiant différents, ils sont tous appelés fichiers "unités". Les unités sont la base de tout systemd.
Les fichiers d'unité sont des fichiers en texte brut ASCII qui sont accessibles et peuvent être créés ou modifiés par un administrateur système. Il existe un certain nombre de types de fichiers d'unité, et chacun a sa propre page de manuel. La figure 1 répertorie certains de ces types de fichiers unitaires par leurs extensions de nom de fichier et une brève description de chacun.
| unité systemd | Description |
|---|---|
| .automount | Le .automount les unités sont utilisées pour implémenter à la demande (c'est-à-dire plug and play) et le montage d'unités de système de fichiers en parallèle lors du démarrage. |
| .appareil | Le .device les fichiers d'unité définissent le matériel et les périphériques virtuels qui sont exposés à l'administrateur système dans le répertoire /dev/ . Tous les appareils n'ont pas de fichiers d'unité; généralement, les périphériques de blocage tels que les disques durs, les périphériques réseau et certains autres ont des fichiers d'unité. |
| .mount | Le .mount unit définit un point de montage sur la structure de répertoires du système de fichiers Linux. |
| .scope | Le .scope définit et gère un ensemble de processus système. Cette unité n'est pas configurée à l'aide de fichiers d'unité, elle est plutôt créée par programmation. Selon systemd.scope page de manuel, "L'objectif principal des unités de portée est de regrouper les processus de travail d'un service système pour l'organisation et la gestion des ressources." |
| .service | Le .service les fichiers d'unité définissent les processus gérés par systemd. Ceux-ci incluent des services tels que crond cups (Common Unix Printing System), iptables, des services de gestion de volumes logiques multiples (LVM), NetworkManager, etc. |
| .slice | Le .slice L'unité définit une "tranche", qui est une division conceptuelle des ressources système liées à un groupe de processus. Vous pouvez considérer toutes les ressources système comme un gâteau et ce sous-ensemble de ressources comme une "part" de ce gâteau. |
| .socket | Le .socket les unités définissent les sockets de communication interprocessus, tels que les sockets réseau. |
| .swap | Le .swap les unités définissent des périphériques ou des fichiers d'échange. |
| .target | La .cible Les unités définissent des groupes de fichiers d'unité qui définissent les points de synchronisation de démarrage, les niveaux d'exécution et les services. Les unités cibles définissent les services et autres unités qui doivent être actifs pour démarrer avec succès. |
| .timer | Le .timer l'unité définit les temporisateurs qui peuvent lancer l'exécution du programme à des moments spécifiés. |
systemctl
J'ai examiné les fonctions de démarrage de systemd dans le deuxième article, et ici j'explorerai un peu plus ses fonctions de gestion des services. systemd fournit le systemctl commande utilisée pour démarrer et arrêter les services, les configurer pour qu'ils se lancent (ou non) au démarrage du système et surveiller l'état actuel des services en cours d'exécution.
Dans une session de terminal en tant qu'utilisateur root, assurez-vous que le répertoire personnel de root ( ~ ) est le PWD. Pour commencer à regarder les unités de différentes manières, répertoriez toutes les unités systemd chargées et actives. systemctl dirige automatiquement son flux de données stdout via le moins téléavertisseur, vous n'avez donc pas à :
[root@testvm1 ~]# systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File>
sys-devices-pci0000:00-0000:00:01.1-ata7-host6-target6:0:0-6:0:0:0-block-sr0.device loaded a>
sys-devices-pci0000:00-0000:00:03.0-net-enp0s3.device loaded active plugged 82540EM Gigabi>
sys-devices-pci0000:00-0000:00:05.0-sound-card0.device loaded active plugged 82801AA AC'97>
sys-devices-pci0000:00-0000:00:08.0-net-enp0s8.device loaded active plugged 82540EM Gigabi>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loa>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device loa>
<snip – removed lots of lines of data from here>
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.
206 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Lorsque vous faites défiler les données dans votre session de terminal, recherchez des éléments spécifiques. La première section répertorie les périphériques tels que les disques durs, les cartes son, les cartes d'interface réseau et les périphériques TTY. Une autre section montre les points de montage du système de fichiers. D'autres sections incluent divers services et une liste de toutes les cibles chargées et actives.
Les temporisateurs sysstat au bas de la sortie sont utilisés pour collecter et générer des résumés quotidiens de l'activité du système pour SAR. SAR est un outil de résolution de problèmes très utile. (Vous pouvez en savoir plus à ce sujet dans le chapitre 13 de mon livre Using and Administering Linux:Volume 1, Zero to SysAdmin:Getting Started .)
Tout en bas, trois lignes décrivent la signification des statuts (chargé, actif et sous). Appuyez sur q pour quitter le téléavertisseur.
Utilisez la commande suivante (comme suggéré dans la dernière ligne de la sortie ci-dessus) pour voir toutes les unités installées, qu'elles soient chargées ou non. Je ne reproduirai pas la sortie ici, car vous pouvez la parcourir vous-même. Le programme systemctl dispose d'une excellente fonction de complétion par tabulation qui facilite la saisie de commandes complexes sans avoir à mémoriser toutes les options :
[root@testvm1 ~]# systemctl list-unit-filesVous pouvez voir que certaines unités sont désactivées. Le tableau 1 de la page de manuel de systemctl répertorie et fournit de brèves descriptions des entrées que vous pourriez voir dans cette liste. Utilisez le -t (type) option pour afficher uniquement les unités de minuterie :
[root@testvm1 ~]# systemctl list-unit-files -t timer
UNIT FILE STATE
[email protected] disabled
dnf-makecache.timer enabled
fstrim.timer disabled
logrotate.timer disabled
logwatch.timer disabled
[email protected] static
mlocate-updatedb.timer enabled
sysstat-collect.timer enabled
sysstat-summary.timer enabled
systemd-tmpfiles-clean.timer static
unbound-anchor.timer enabled
Vous pourriez faire la même chose avec cette alternative, qui fournit beaucoup plus de détails :
[root@testvm1 ~]# systemctl list-timers
Thu 2020-04-16 09:06:20 EDT 3min 59s left n/a n/a systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2020-04-16 10:02:01 EDT 59min left Thu 2020-04-16 09:01:32 EDT 49s ago dnf-makecache.timer dnf-makecache.service
Thu 2020-04-16 13:00:00 EDT 3h 57min left n/a n/a sysstat-collect.timer sysstat-collect.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left mlocate-updatedb.timer mlocate-updatedb.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left unbound-anchor.timer unbound-anchor.service
Fri 2020-04-17 00:07:00 EDT 15h left n/a n/a sysstat-summary.timer sysstat-summary.service
6 timers listed.
Pass --all to see loaded but inactive timers, too.
[root@testvm1 ~]#
Bien qu'il n'y ait pas d'option pour effectuer des montages de liste systemctl, vous pouvez lister les fichiers d'unité de point de montage :
[root@testvm1 ~]# systemctl list-unit-files -t mount
UNIT FILE STATE
-.mount generated
boot.mount generated
dev-hugepages.mount static
dev-mqueue.mount static
home.mount generated
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount disabled
run-vmblock\x2dfuse.mount disabled
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount generated
usr.mount generated
var-lib-nfs-rpc_pipefs.mount static
var.mount generated
15 unit files listed.
[root@testvm1 ~]#
La colonne STATE de ce flux de données est intéressante et nécessite quelques explications. Les états "générés" indiquent que l'unité de montage a été générée à la volée lors du démarrage à l'aide des informations contenues dans /etc/fstab . Le programme qui génère ces unités de montage est /lib/systemd/system-generators/systemd-fstab-generator, ainsi que d'autres outils qui génèrent un certain nombre d'autres types d'unités. Les unités de montage "statiques" sont pour les systèmes de fichiers comme /proc et /sys , et les fichiers correspondants se trouvent dans le répertoire /usr/lib/systemd/system répertoire.
Maintenant, regardez les unités de service. Cette commande affichera tous les services installés sur l'hôte, qu'ils soient actifs ou non :
[root@testvm1 ~]# systemctl --all -t serviceLe bas de cette liste d'unités de service affiche 166 comme le nombre total d'unités chargées sur mon hôte. Votre numéro sera probablement différent.
Les fichiers d'unité n'ont pas d'extension de nom de fichier (comme .unit ) pour aider à les identifier, vous pouvez donc généraliser que la plupart des fichiers de configuration appartenant à systemd sont des fichiers unitaires d'un type ou d'un autre. Les quelques fichiers restants sont principalement .conf fichiers situés dans /etc/systemd .
Les fichiers d'unité sont stockés dans /usr/lib/systemd répertoire et ses sous-répertoires, tandis que le répertoire /etc/systemd/ répertoire et ses sous-répertoires contiennent des liens symboliques vers les fichiers unitaires nécessaires à la configuration locale de cet hôte.
Pour explorer cela, créez /etc/systemd le PWD et lister son contenu. Créez ensuite /etc/systemd/system le PWD et lister son contenu, et lister le contenu d'au moins quelques sous-répertoires du PWD actuel.
Jetez un œil à la default.target fichier, qui détermine sur quelle cible de niveau d'exécution le système démarrera. Dans le deuxième article de cette série, j'ai expliqué comment changer la cible par défaut de l'interface graphique (graphical.target ) à la ligne de commande uniquement (multi-user.target ) cibler. La cible par défaut le fichier sur ma machine virtuelle de test est simplement un lien symbolique vers /usr/lib/systemd/system/graphical.target .
Prenez quelques minutes pour examiner le contenu de /etc/systemd/system/default.target fichier :
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Graphical Interface
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
Notez que cela nécessite le multi-user.target; la cible.graphique ne peut pas démarrer si le multi-user.target n'est pas déjà opérationnel. Il dit également qu'il "veut" le display-manager.service unité. Un "désir" n'a pas besoin d'être satisfait pour que l'unité démarre avec succès. Si le "vouloir" ne peut pas être satisfait, il sera ignoré par systemd, et le reste de la cible démarrera malgré tout.
Les sous-répertoires dans /etc/systemd/system sont des listes de désirs pour diverses cibles. Prenez quelques minutes pour explorer les fichiers et leur contenu dans /etc/systemd/system/graphical.target.wants répertoire.
Le systemd.unit La page de manuel contient de nombreuses informations utiles sur les fichiers d'unité, leur structure, les sections dans lesquelles ils peuvent être divisés et les options qui peuvent être utilisées. Il répertorie également de nombreux types d'unités, qui ont tous leurs propres pages de manuel. Si vous souhaitez interpréter un fichier d'unité, ce serait un bon point de départ.
Unités de service
Une installation Fedora installe et active généralement des services dont certains hôtes n'ont pas besoin pour un fonctionnement normal. À l'inverse, il arrive parfois qu'il n'inclue pas les services qui doivent être installés, activés et démarrés. Les services qui ne sont pas nécessaires pour que l'hôte Linux fonctionne comme souhaité, mais qui sont installés et éventuellement en cours d'exécution, représentent un risque de sécurité et doivent, au minimum, être arrêtés et désactivés et, au mieux, doivent être désinstallés.
La commande systemctl est utilisée pour gérer les unités systemd, y compris les services, les cibles, les montages, etc. Examinez de plus près la liste des services pour identifier les services qui ne seront jamais utilisés :
[root@testvm1 ~]# systemctl --all -t service
UNIT LOAD ACTIVE SUB DESCRIPTION
<snip>
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
cups.service loaded active running CUPS Scheduler
dbus-daemon.service loaded active running D-Bus System Message Bus
<snip>
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
<snip>
firewalld.service loaded active running firewalld - dynamic firewall daemon
<snip>
● ntpd.service not-found inactive dead ntpd.service
● ntpdate.service not-found inactive dead ntpdate.service
pcscd.service loaded active running PC/SC Smart Card Daemon
J'ai supprimé la majeure partie de la sortie de la commande pour économiser de l'espace. Les services qui affichent "l'exécution active chargée" sont évidents. Les services "non trouvés" sont ceux que systemd connaît mais qui ne sont pas installés sur l'hôte Linux. Si vous souhaitez exécuter ces services, vous devez installer les packages qui les contiennent.
Notez le pcscd.service unité. Il s'agit du démon de carte à puce PC/SC. Sa fonction est de communiquer avec les lecteurs de cartes à puce. De nombreux hôtes Linux, y compris les machines virtuelles, n'ont pas besoin de ce lecteur ni du service qui est chargé et qui consomme de la mémoire et des ressources CPU. Vous pouvez arrêter ce service et le désactiver, afin qu'il ne redémarre pas au prochain démarrage. Vérifiez d'abord son état :
[root@testvm1 ~]# systemctl status pcscd.service
● pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
Active: active (running) since Fri 2019-05-10 11:28:42 EDT; 3 days ago
Docs: man:pcscd(8)
Main PID: 24706 (pcscd)
Tasks: 6 (limit: 4694)
Memory: 1.6M
CGroup: /system.slice/pcscd.service
└─24706 /usr/sbin/pcscd --foreground --auto-exit
May 10 11:28:42 testvm1 systemd[1]: Started PC/SC Smart Card Daemon.
Ces données illustrent les informations supplémentaires fournies par systemd par rapport à SystemV, qui indique uniquement si le service est en cours d'exécution ou non. Notez que spécifier le .service le type d'unité est facultatif. Maintenant, arrêtez et désactivez le service, puis revérifiez son état :
[root@testvm1 ~]# systemctl stop pcscd ; systemctl disable pcscd
Warning: Stopping pcscd.service, but it can still be activated by:
pcscd.socket
Removed /etc/systemd/system/sockets.target.wants/pcscd.socket.
[root@testvm1 ~]# systemctl status pcscd
● pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-05-13 15:23:15 EDT; 48s ago
Docs: man:pcscd(8)
Main PID: 24706 (code=exited, status=1/FAILURE)
May 10 11:28:42 testvm1 systemd[1]: Started PC/SC Smart Card Daemon.
May 13 15:23:15 testvm1 systemd[1]: Stopping PC/SC Smart Card Daemon...
May 13 15:23:15 testvm1 systemd[1]: pcscd.service: Main process exited, code=exited, status=1/FAIL>
May 13 15:23:15 testvm1 systemd[1]: pcscd.service: Failed with result 'exit-code'.
May 13 15:23:15 testvm1 systemd[1]: Stopped PC/SC Smart Card Daemon.
L'affichage court des entrées de journal pour la plupart des services évite d'avoir à rechercher dans divers fichiers journaux pour localiser ce type d'informations. Vérifiez l'état des cibles de niveau d'exécution du système. La spécification du type d'unité "cible" est obligatoire :
[root@testvm1 ~]# systemctl status multi-user.target
● multi-user.target - Multi-User System
Loaded: loaded (/usr/lib/systemd/system/multi-user.target; static; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Multi-User System.
[root@testvm1 ~]# systemctl status graphical.target
● graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Graphical Interface.
[root@testvm1 ~]# systemctl status default.target
● graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Graphical Interface.
La cible par défaut est la cible graphique. Le statut de n'importe quelle unité peut être vérifié de cette manière.
Monte à l'ancienne
Une unité de montage définit tous les paramètres requis pour monter un système de fichiers sur un point de montage désigné. systemd peut gérer les unités de montage avec plus de flexibilité que celles utilisant /etc/fstab fichier de configuration du système de fichiers. Malgré cela, systemd utilise toujours le /etc/fstab fichier à des fins de configuration et de montage du système de fichiers. systemd utilise le systemd-fstab-generator outil pour créer des unités de montage transitoires à partir des données du fstab fichier.
Je vais créer un nouveau système de fichiers et une unité de montage systemd pour le monter. Si vous avez de l'espace disque disponible sur votre système de test, vous pouvez le faire avec moi.
Notez que les noms de groupe de volumes et de volumes logiques peuvent être différents sur votre système de test. Veillez à utiliser les noms pertinents pour votre système.
Vous devrez créer une partition ou un volume logique, puis y créer un système de fichiers EXT4. Ajoutez une étiquette au système de fichiers, TestFS , et créez un répertoire pour un point de montage /TestFS .
Pour essayer cela par vous-même, vérifiez d'abord que vous disposez d'espace libre sur le groupe de volumes. Voici à quoi cela ressemble sur ma machine virtuelle où j'ai de l'espace disponible sur le groupe de volumes pour créer un nouveau volume logique :
[root@testvm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda1 8:1 0 4G 0 part /boot
└─sda2 8:2 0 116G 0 part
├─VG01-root 253:0 0 5G 0 lvm /
├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
├─VG01-usr 253:2 0 30G 0 lvm /usr
├─VG01-home 253:3 0 20G 0 lvm /home
├─VG01-var 253:4 0 20G 0 lvm /var
└─VG01-tmp 253:5 0 10G 0 lvm /tmp
sr0 11:0 1 1024M 0 rom
[root@testvm1 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
VG01 1 6 0 wz--n- <116.00g <23.00g
Créez ensuite un nouveau volume sur VG01 nommé TestFS . Il n'a pas besoin d'être grand; 1 Go c'est bien. Créez ensuite un système de fichiers, ajoutez l'étiquette du système de fichiers et créez le point de montage :
[root@testvm1 ~]# lvcreate -L 1G -n TestFS VG01
Logical volume "TestFS" created.
[root@testvm1 ~]# mkfs -t ext4 /dev/mapper/VG01-TestFS
mke2fs 1.45.3 (14-Jul-2019)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 8718fba9-419f-4915-ab2d-8edf811b5d23
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
[root@testvm1 ~]# e2label /dev/mapper/VG01-TestFS TestFS
[root@testvm1 ~]# mkdir /TestFS
Maintenant, montez le nouveau système de fichiers :
[root@testvm1 ~]# mount /TestFS/
mount: /TestFS/: can't find in /etc/fstab.
Cela ne fonctionnera pas car vous n'avez pas d'entrée dans /etc/fstab . Vous pouvez monter le nouveau système de fichiers même sans l'entrée dans /etc/fstab en utilisant à la fois le nom de l'appareil (tel qu'il apparaît dans /dev ) et le point de montage. Le montage de cette manière est plus simple qu'auparavant - il nécessitait auparavant le type de système de fichiers comme argument. La commande mount est désormais suffisamment intelligente pour détecter le type de système de fichiers et le monter en conséquence.
Essayez à nouveau :
[root@testvm1 ~]# mount /dev/mapper/VG01-TestFS /TestFS/
[root@testvm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda1 8:1 0 4G 0 part /boot
└─sda2 8:2 0 116G 0 part
├─VG01-root 253:0 0 5G 0 lvm /
├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
├─VG01-usr 253:2 0 30G 0 lvm /usr
├─VG01-home 253:3 0 20G 0 lvm /home
├─VG01-var 253:4 0 20G 0 lvm /var
├─VG01-tmp 253:5 0 10G 0 lvm /tmp
└─VG01-TestFS 253:6 0 1G 0 lvm /TestFS
sr0 11:0 1 1024M 0 rom
[root@testvm1 ~]#
Maintenant, le nouveau système de fichiers est monté au bon endroit. Répertoriez les fichiers d'unité de montage :
[root@testvm1 ~]# systemctl list-unit-files -t mountCette commande n'affiche pas de fichier pour /TestFS système de fichiers car aucun fichier n'existe pour celui-ci. La commande systemctl status TestFS.mount n'affiche pas non plus d'informations sur le nouveau système de fichiers. Vous pouvez l'essayer en utilisant des caractères génériques avec le statut systemctl commande :
[root@testvm1 ~]# systemctl status *mount
● usr.mount - /usr
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted)
Where: /usr
What: /dev/mapper/VG01-usr
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
<SNIP>
● TestFS.mount - /TestFS
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Fri 2020-04-17 16:02:26 EDT; 1min 18s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
● run-user-0.mount - /run/user/0
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Thu 2020-04-16 08:52:29 EDT; 1 day 5h ago
Where: /run/user/0
What: tmpfs
● var.mount - /var
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Thu 2020-04-16 12:51:34 EDT; 1 day 1h ago
Where: /var
What: /dev/mapper/VG01-var
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 19166)
Memory: 212.0K
CPU: 5ms
CGroup: /system.slice/var.mount
Cette commande fournit des informations très intéressantes sur les montages de votre système et votre nouveau système de fichiers apparaît. Le /var et /usr les systèmes de fichiers sont identifiés comme étant générés à partir de /etc/fstab , tandis que votre nouveau système de fichiers indique simplement qu'il est chargé et fournit l'emplacement du fichier d'informations dans /proc/self/mountinfo fichier.
Ensuite, automatisez ce montage. Tout d'abord, faites-le à l'ancienne en ajoutant une entrée dans /etc/fstab . Plus tard, je vous montrerai comment procéder de la nouvelle manière, ce qui vous apprendra à créer des unités et à les intégrer dans la séquence de démarrage.
Démontez /TestFS et ajoutez la ligne suivante au /etc/fstab fichier :
/dev/mapper/VG01-TestFS /TestFS ext4 defaults 1 2Maintenant, montez le système de fichiers avec le montage plus simple commande et liste à nouveau les unités de montage :
[root@testvm1 ~]# mount /TestFS
[root@testvm1 ~]# systemctl status *mount
<SNIP>
● TestFS.mount - /TestFS
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Fri 2020-04-17 16:26:44 EDT; 1min 14s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
<SNIP>
Cela n'a pas modifié les informations de ce montage car le système de fichiers a été monté manuellement. Redémarrez et exécutez à nouveau la commande, et cette fois spécifiez TestFS.mount plutôt que d'utiliser le caractère générique. Les résultats de ce montage sont désormais cohérents avec son montage au démarrage :
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - /TestFS
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Fri 2020-04-17 16:30:21 EDT; 1min 38s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 19166)
Memory: 72.0K
CPU: 6ms
CGroup: /system.slice/TestFS.mount
Apr 17 16:30:21 testvm1 systemd[1]: Mounting /TestFS...
Apr 17 16:30:21 testvm1 systemd[1]: Mounted /TestFS.
Création d'une unité de montage
Mount units may be configured either with the traditional /etc/fstab file or with systemd units. Fedora uses the fstab file as it is created during the installation. However, systemd uses the systemd-fstab-generator program to translate the fstab file into systemd units for each entry in the fstab dossier. Now that you know you can use systemd .mount unit files for filesystem mounting, try it out by creating a mount unit for this filesystem.
First, unmount /TestFS . Edit the /etc/fstab file and delete or comment out the TestFS line. Now, create a new file with the name TestFS.mount in the /etc/systemd/system annuaire. Edit it to contain the configuration data below. The unit file name and the name of the mount point must be identical, or the mount will fail:
# This mount unit is for the TestFS filesystem
# By David Both
# Licensed under GPL V2
# This file should be located in the /etc/systemd/system directory
[Unit]
Description=TestFS Mount
[Mount]
What=/dev/mapper/VG01-TestFS
Where=/TestFS
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
The Description line in the [Unit] section is for us humans, and it provides the name that's shown when you list mount units with systemctl -t mount . The data in the [Mount] section of this file contains essentially the same data that would be found in the fstab fichier.
Now enable the mount unit:
[root@testvm1 etc]# systemctl enable TestFS.mount
Created symlink /etc/systemd/system/multi-user.target.wants/TestFS.mount → /etc/systemd/system/TestFS.mount.
This creates the symlink in the /etc/systemd/system directory, which will cause this mount unit to be mounted on all subsequent boots. The filesystem has not yet been mounted, so you must "start" it:
[root@testvm1 ~]# systemctl start TestFS.mountVerify that the filesystem has been mounted:
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - TestFS Mount
Loaded: loaded (/etc/systemd/system/TestFS.mount; enabled; vendor preset: disabled)
Active: active (mounted) since Sat 2020-04-18 09:59:53 EDT; 14s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
Tasks: 0 (limit: 19166)
Memory: 76.0K
CPU: 3ms
CGroup: /system.slice/TestFS.mount
Apr 18 09:59:53 testvm1 systemd[1]: Mounting TestFS Mount...
Apr 18 09:59:53 testvm1 systemd[1]: Mounted TestFS Mount.
This experiment has been specifically about creating a unit file for a mount, but it can be applied to other types of unit files as well. The details will be different, but the concepts are the same. Yes, I know it is still easier to add a line to the /etc/fstab file than it is to create a mount unit. But this is a good example of how to create a unit file because systemd does not have generators for every type of unit.
In summary
This article looked at systemd units in more detail and how to use the systemctl command to explore and manage units. It also showed how to stop and disable units and create a new systemd mount unit to mount a new filesystem and enable it to initiate during startup.
In the next article in this series, I will take you through a recent problem I had during startup and show you how I circumvented it using systemd.
Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI