In den ersten beiden Artikeln dieser Reihe habe ich die Startsequenz von Linux systemd untersucht. Im ersten Artikel habe ich die Funktionen und die Architektur von systemd und die Kontroverse um seine Rolle als Ersatz für das alte SystemV-Init-Programm und die Startskripte betrachtet. Und im zweiten Artikel habe ich zwei wichtige systemd-Tools untersucht, systemctl und journalctl, und erklärt, wie man von einem Ziel zu einem anderen wechselt und das Standardziel ändert.
In diesem dritten Artikel schaue ich mir die systemd-Units genauer an und wie man den systemctl-Befehl verwendet, um Units zu durchsuchen und zu verwalten. Ich werde auch erklären, wie man Units stoppt und deaktiviert und wie man eine neue Systemd-Mount-Unit erstellt, um ein neues Dateisystem zu mounten und zu ermöglichen, es während des Starts zu initiieren.
Vorbereitung
Mehr über Systemadministratoren
- Sysadmin-Blog aktivieren
- Das automatisierte Unternehmen:ein Leitfaden zur IT-Verwaltung mit Automatisierung
- eBook:Ansible-Automatisierung für SysAdmins
- Geschichten aus der Praxis:Ein Leitfaden für Systemadministratoren zur IT-Automatisierung
- eBook:Ein Leitfaden zu Kubernetes für SREs und Systemadministratoren
- Neueste Sysadmin-Artikel
Alle Experimente in diesem Artikel sollten als Root-Benutzer durchgeführt werden (sofern nicht anders angegeben). Einige der Befehle, die einfach verschiedene systemd-Einheiten auflisten, können von Nicht-Root-Benutzern ausgeführt werden, aber die Befehle, die Änderungen vornehmen, können dies nicht. Stellen Sie sicher, dass Sie alle diese Experimente nur auf Nicht-Produktionshosts oder virtuellen Maschinen (VMs) durchführen.
Eines dieser Experimente erfordert das sysstat-Paket, also installieren Sie es, bevor Sie fortfahren. Für Fedora und andere Red Hat-basierte Distributionen können Sie sysstat installieren mit:
dnf -y install sysstatDas sysstat-RPM installiert mehrere statistische Tools, die zur Problembestimmung verwendet werden können. Einer ist der System Activity Report (SAR), der viele Datenpunkte zur Systemleistung in regelmäßigen Abständen (standardmäßig alle 10 Minuten) aufzeichnet. Anstatt als Daemon im Hintergrund ausgeführt zu werden, installiert das sysstat-Paket zwei systemd-Timer. Ein Timer läuft alle 10 Minuten, um Daten zu sammeln, und der andere läuft einmal am Tag, um die täglichen Daten zu aggregieren. In diesem Artikel werde ich kurz auf diese Timer eingehen, aber ich warte darauf, in einem zukünftigen Artikel zu erklären, wie man einen Timer erstellt.
Systemd-Suite
Tatsache ist, dass systemd mehr als nur ein Programm ist. Es ist eine große Suite von Programmen, die alle darauf ausgelegt sind, zusammenzuarbeiten, um fast jeden Aspekt eines laufenden Linux-Systems zu verwalten. Eine vollständige Darstellung von systemd würde ein eigenes Buch erfordern. Die meisten von uns müssen nicht alle Details darüber verstehen, wie alle Komponenten von systemd zusammenpassen, daher werde ich mich auf die Programme und Komponenten konzentrieren, die es Ihnen ermöglichen, verschiedene Linux-Dienste zu verwalten und mit Protokolldateien und Journalen umzugehen.
Praktische Struktur
Die Struktur von systemd – abgesehen von seinen ausführbaren Dateien – ist in seinen vielen Konfigurationsdateien enthalten. Obwohl diese Dateien unterschiedliche Namen und Kennungserweiterungen haben, werden sie alle als "Unit"-Dateien bezeichnet. Einheiten sind die Basis von allem Systemd.
Unit-Dateien sind ASCII-Dateien im Klartext, die für einen Systemadministrator zugänglich sind und von diesem erstellt oder geändert werden können. Es gibt eine Reihe von Unit-Dateitypen, und jeder hat seine eigene Handbuchseite. Abbildung 1 listet einige dieser Unit-Dateitypen nach ihren Dateinamenerweiterungen und jeweils einer kurzen Beschreibung auf.
| Systemeinheit | Beschreibung |
|---|---|
| .automount | Die .automount Units werden verwendet, um On-Demand (d. h. Plug-and-Play) und paralleles Mounten von Dateisystem-Units während des Starts zu implementieren. |
| .Gerät | Das .Gerät Unit-Dateien definieren Hardware und virtuelle Geräte, die dem Systemadministrator im /dev/directory angezeigt werden . Nicht alle Geräte haben Einheitendateien; Typischerweise haben Blockgeräte wie Festplatten, Netzwerkgeräte und einige andere Unit-Dateien. |
| .mount | Die .mount unit definiert einen Einhängepunkt in der Verzeichnisstruktur des Linux-Dateisystems. |
| .scope | Der .scope Unit definiert und verwaltet eine Reihe von Systemprozessen. Diese Unit wird nicht mithilfe von Unit-Dateien konfiguriert, sondern programmgesteuert erstellt. Gemäß systemd.scope Manpage, „Der Hauptzweck von Bereichseinheiten ist das Gruppieren von Arbeitsprozessen eines Systemdienstes zur Organisation und zum Verwalten von Ressourcen.“ |
| .service | Der .service Unit-Dateien definieren Prozesse, die von systemd verwaltet werden. Dazu gehören Dienste wie crond cups (Common Unix Printing System), iptables, Multiple Logical Volume Management (LVM)-Dienste, NetworkManager und mehr. |
| .slice | Das .slice unit definiert einen „Slice“, der eine konzeptionelle Unterteilung von Systemressourcen darstellt, die sich auf eine Gruppe von Prozessen beziehen. Sie können sich alle Systemressourcen als einen Kuchen und diese Teilmenge von Ressourcen als ein „Stück“ aus diesem Kuchen vorstellen. |
| .socket | Die .socket Units definieren Interprozess-Kommunikations-Sockets, wie etwa Netzwerk-Sockets. |
| .swap | Die .swap Einheiten definieren Auslagerungsgeräte oder Dateien. |
| .target | Das .target Units definieren Gruppen von Unit-Dateien, die Startup-Synchronisationspunkte, Runlevels und Dienste definieren. Zieleinheiten definieren die Dienste und andere Einheiten, die aktiv sein müssen, um erfolgreich zu starten. |
| .timer | Der .timer unit definiert Timer, die die Programmausführung zu bestimmten Zeiten einleiten können. |
systemctl
Ich habe mir die Startfunktionen von systemd im zweiten Artikel angesehen, und hier werde ich die Dienstverwaltungsfunktionen etwas weiter untersuchen. systemd stellt das systemctl bereit Befehl, der verwendet wird, um Dienste zu starten und zu stoppen, sie so zu konfigurieren, dass sie beim Systemstart gestartet (oder nicht) werden, und den aktuellen Status laufender Dienste zu überwachen.
Stellen Sie in einer Terminalsitzung als Root-Benutzer sicher, dass das Home-Verzeichnis von Root ( ~ ) ist die PWD. Um zu beginnen, Units auf verschiedene Weise zu betrachten, listen Sie alle geladenen und aktiven systemd-Units auf. systemctl leitet seinen stdout-Datenstrom automatisch durch less Pager, sodass Sie Folgendes nicht tun müssen:
[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'.
Achten Sie beim Scrollen durch die Daten in Ihrer Terminalsitzung auf bestimmte Dinge. Der erste Abschnitt listet Geräte wie Festplatten, Soundkarten, Netzwerkschnittstellenkarten und TTY-Geräte auf. Ein weiterer Abschnitt zeigt die Einhängepunkte des Dateisystems. Andere Abschnitte enthalten verschiedene Dienste und eine Liste aller geladenen und aktiven Ziele.
Die Sysstat-Timer unten in der Ausgabe werden verwendet, um Zusammenfassungen der täglichen Systemaktivität für SAR zu sammeln und zu generieren. SAR ist ein sehr nützliches Werkzeug zur Problemlösung. (Sie können mehr darüber in Kapitel 13 meines Buches Using and Administering Linux:Volume 1, Zero to SysAdmin:Getting Started erfahren .)
Ganz unten beschreiben drei Zeilen die Bedeutung der Status (geladen, aktiv und sub). Drücken Sie q um den Pager zu verlassen.
Verwenden Sie den folgenden Befehl (wie in der letzten Zeile der obigen Ausgabe vorgeschlagen), um alle installierten Einheiten anzuzeigen, unabhängig davon, ob sie geladen sind oder nicht. Ich werde die Ausgabe hier nicht wiedergeben, da Sie sie selbst durchblättern können. Das systemctl-Programm hat eine ausgezeichnete Funktion zum Vervollständigen von Tabs, die es einfach macht, komplexe Befehle einzugeben, ohne sich alle Optionen merken zu müssen:
[root@testvm1 ~]# systemctl list-unit-filesSie können sehen, dass einige Einheiten deaktiviert sind. Tabelle 1 in der Manpage für systemctl listet auf und enthält kurze Beschreibungen der Einträge, die Sie möglicherweise in dieser Auflistung sehen. Verwenden Sie das -t (Typ)-Option, um nur die Timer-Einheiten anzuzeigen:
[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
Sie könnten dasselbe mit dieser Alternative tun, die erheblich mehr Details bietet:
[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 ~]#
Obwohl es keine Option gibt, systemctl list-mounts durchzuführen, können Sie die Mount-Point-Unit-Dateien auflisten:
[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 ~]#
Die Spalte STATE in diesem Datenstrom ist interessant und erfordert ein wenig Erklärung. Die „generated“-Zustände zeigen an, dass die Mount-Unit während des Starts unter Verwendung der Informationen in /etc/fstab on-the-fly generiert wurde . Das Programm, das diese Mount-Units generiert, ist /lib/systemd/system-generators/systemd-fstab-generator, zusammen mit anderen Werkzeugen, die eine Reihe anderer Einheitentypen generieren. Die "statischen" Mount-Units sind für Dateisysteme wie /proc und /sys , und die Dateien dafür befinden sich im /usr/lib/systemd/system Verzeichnis.
Schauen Sie sich jetzt die Serviceeinheiten an. Dieser Befehl zeigt alle auf dem Host installierten Dienste an, unabhängig davon, ob sie aktiv sind oder nicht:
[root@testvm1 ~]# systemctl --all -t serviceUnten in dieser Liste der Serviceeinheiten wird 166 als Gesamtzahl der geladenen Einheiten auf meinem Host angezeigt. Ihre Nummer wird wahrscheinlich anders sein.
Unit-Dateien haben keine Dateinamenerweiterung (z. B. .unit ), um sie zu identifizieren, sodass Sie verallgemeinern können, dass die meisten Konfigurationsdateien, die zu systemd gehören, Unit-Dateien des einen oder anderen Typs sind. Die wenigen verbleibenden Dateien sind meistens .conf Dateien in /etc/systemd .
Unit-Dateien werden in /usr/lib/systemd gespeichert Verzeichnis und seine Unterverzeichnisse, während /etc/systemd/ Verzeichnis und seine Unterverzeichnisse enthalten symbolische Links zu den Unit-Dateien, die für die lokale Konfiguration dieses Hosts notwendig sind.
Um dies zu untersuchen, erstellen Sie /etc/systemd das PWD und seinen Inhalt auflisten. Dann machen Sie /etc/systemd/system das PWD und seinen Inhalt auflisten und den Inhalt von mindestens einigen Unterverzeichnissen des aktuellen PWD auflisten.
Werfen Sie einen Blick auf default.target Datei, die festlegt, zu welchem Runlevel-Ziel das System booten wird. Im zweiten Artikel dieser Serie habe ich erklärt, wie man das Standardziel über die GUI ändert (graphical.target ) nur an die Befehlszeile (multi-user.target ) Ziel. Das default.target Datei auf meiner Test-VM ist einfach ein symbolischer Link zu /usr/lib/systemd/system/graphical.target .
Nehmen Sie sich ein paar Minuten Zeit, um den Inhalt von /etc/systemd/system/default.target zu untersuchen Datei:
[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
Beachten Sie, dass hierfür das multi-user.target erforderlich ist; das graphical.target kann nicht gestartet werden, wenn multi-user.target ist noch nicht in Betrieb. Es sagt auch, dass es den display-manager.service "will". Einheit. Ein „Wunsch“ muss nicht erfüllt sein, damit die Einheit erfolgreich starten kann. Wenn der "Wunsch" nicht erfüllt werden kann, wird er von Systemd ignoriert und der Rest des Ziels wird trotzdem gestartet.
Die Unterverzeichnisse in /etc/systemd/system sind Wunschlisten für verschiedene Ziele. Nehmen Sie sich ein paar Minuten Zeit, um die Dateien und ihren Inhalt in /etc/systemd/system/graphical.target.wants zu erkunden Verzeichnis.
Die systemd.unit Manpage enthält viele gute Informationen über Unit-Dateien, ihre Struktur, die Abschnitte, in die sie unterteilt werden können, und die Optionen, die verwendet werden können. Es listet auch viele der Unit-Typen auf, die alle ihre eigenen Handbuchseiten haben. Wenn Sie eine Unit-Datei interpretieren möchten, wäre dies ein guter Ausgangspunkt.
Serviceeinheiten
Eine Fedora-Installation installiert und aktiviert normalerweise Dienste, die bestimmte Hosts für den normalen Betrieb nicht benötigen. Umgekehrt enthält es manchmal keine Dienste, die installiert, aktiviert und gestartet werden müssen. Dienste, die für die gewünschte Funktion des Linux-Hosts nicht benötigt werden, aber installiert sind und möglicherweise ausgeführt werden, stellen ein Sicherheitsrisiko dar und sollten – zumindest – gestoppt und deaktiviert und – bestenfalls – deinstalliert werden.
Der Befehl systemctl wird verwendet, um systemd-Einheiten zu verwalten, einschließlich Dienste, Ziele, Mounts und mehr. Sehen Sie sich die Liste der Dienste genauer an, um Dienste zu identifizieren, die niemals verwendet werden:
[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
Ich habe den größten Teil der Ausgabe des Befehls entfernt, um Platz zu sparen. Die Dienste, die "loaded active running" anzeigen, sind offensichtlich. Die "nicht gefundenen" Dienste sind diejenigen, die systemd kennt, aber nicht auf dem Linux-Host installiert sind. Wenn Sie diese Dienste ausführen möchten, müssen Sie die Pakete installieren, die sie enthalten.
Beachten Sie den pcscd.service Einheit. Dies ist der PC/SC-Smartcard-Daemon. Seine Funktion besteht darin, mit Chipkartenlesern zu kommunizieren. Viele Linux-Hosts – einschließlich VMs – benötigen weder diesen Reader noch den Dienst, der geladen wird und Speicher- und CPU-Ressourcen beansprucht. Sie können diesen Dienst stoppen und deaktivieren, sodass er beim nächsten Start nicht neu gestartet wird. Überprüfen Sie zuerst den Status:
[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.
Diese Daten veranschaulichen die zusätzlichen Informationen, die systemd im Vergleich zu SystemV bereitstellt, das nur meldet, ob der Dienst ausgeführt wird oder nicht. Beachten Sie, dass die Angabe von .service Einheitentyp ist optional. Beenden und deaktivieren Sie nun den Dienst und überprüfen Sie dann erneut seinen Status:
[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.
Die kurze Protokolleintragsanzeige für die meisten Dienste verhindert, dass Sie verschiedene Protokolldateien durchsuchen müssen, um diese Art von Informationen zu finden. Überprüfen Sie den Status der Runlevel-Ziele des Systems – die Angabe des Unit-Typs „Ziel“ ist erforderlich:
[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.
Das Standardziel ist das grafische Ziel. Auf diese Weise kann der Status jeder Einheit überprüft werden.
Bereitgestellt auf die alte Art
Eine Einhängeeinheit definiert alle Parameter, die zum Einhängen eines Dateisystems an einem bestimmten Einhängepunkt erforderlich sind. systemd kann Einhängeeinheiten flexibler verwalten als diejenigen, die /etc/fstab verwenden Dateisystem-Konfigurationsdatei. Trotzdem verwendet systemd immer noch die /etc/fstab Datei zur Dateisystemkonfiguration und zum Mounten. systemd verwendet den systemd-fstab-generator Werkzeug zum Erstellen transienter Mount-Einheiten aus den Daten in der fstab Datei.
Ich werde ein neues Dateisystem und eine systemd-Mount-Unit erstellen, um es zu mounten. Wenn Sie auf Ihrem Testsystem etwas freien Speicherplatz haben, können Sie dies gemeinsam mit mir tun.
Beachten Sie, dass die Volumengruppen- und logischen Volumennamen auf Ihrem Testsystem unterschiedlich sein können. Achten Sie darauf, die Namen zu verwenden, die für Ihr System relevant sind.
Sie müssen eine Partition oder ein logisches Volume erstellen und dann ein EXT4-Dateisystem darauf erstellen. Fügen Sie dem Dateisystem ein Label hinzu, TestFS , und erstellen Sie ein Verzeichnis für einen Einhängepunkt /TestFS .
Um dies selbst auszuprobieren, vergewissern Sie sich zunächst, dass Sie freien Speicherplatz in der Volume-Gruppe haben. So sieht das auf meiner VM aus, wo ich in der Volume-Gruppe etwas Speicherplatz zur Verfügung habe, um ein neues logisches Volume zu erstellen:
[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
Erstellen Sie dann ein neues Volume auf VG01 mit dem Namen TestFS . Es muss nicht groß sein; 1 GB ist in Ordnung. Erstellen Sie dann ein Dateisystem, fügen Sie das Dateisystem-Label hinzu und erstellen Sie den Einhängepunkt:
[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
Mounten Sie nun das neue Dateisystem:
[root@testvm1 ~]# mount /TestFS/
mount: /TestFS/: can't find in /etc/fstab.
Dies wird nicht funktionieren, da Sie keinen Eintrag in /etc/fstab haben . Sie können das neue Dateisystem auch ohne den Eintrag in /etc/fstab einhängen Verwenden Sie sowohl den Gerätenamen (wie er in /dev erscheint ) und den Einhängepunkt. Das Mounten auf diese Weise ist einfacher als früher – früher war der Dateisystemtyp als Argument erforderlich. Der Mount-Befehl ist jetzt intelligent genug, um den Dateisystemtyp zu erkennen und ihn entsprechend zu mounten.
Versuchen Sie es erneut:
[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 ~]#
Jetzt wird das neue Dateisystem an der richtigen Stelle gemountet. Listen Sie die Mount-Unit-Dateien auf:
[root@testvm1 ~]# systemctl list-unit-files -t mountDieser Befehl zeigt keine Datei für /TestFS an Dateisystem, weil keine Datei dafür existiert. Der Befehl systemctl status TestFS.mount zeigt auch keine Informationen über das neue Dateisystem an. Sie können es mit Wildcards mit dem systemctl status versuchen Befehl:
[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
Dieser Befehl liefert einige sehr interessante Informationen über die Mounts Ihres Systems, und Ihr neues Dateisystem wird angezeigt. Die /var und /usr Dateisysteme werden als von /etc/fstab generiert identifiziert , während Ihr neues Dateisystem lediglich anzeigt, dass es geladen ist, und den Speicherort der Infodatei in /proc/self/mountinfo angibt Datei.
Als nächstes automatisieren Sie diesen Mount. Machen Sie es zunächst auf altmodische Weise, indem Sie einen Eintrag in /etc/fstab hinzufügen . Später zeige ich Ihnen, wie es auf die neue Art und Weise geht, wodurch Sie lernen, Einheiten zu erstellen und sie in die Startsequenz zu integrieren.
Unmounten Sie /TestFS und fügen Sie die folgende Zeile zu /etc/fstab hinzu Datei:
/dev/mapper/VG01-TestFS /TestFS ext4 defaults 1 2Mounten Sie nun das Dateisystem mit dem einfacheren mount Befehl und listen Sie die Mount-Units erneut auf:
[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>
Dies hat die Informationen für diesen Mount nicht geändert, da das Dateisystem manuell gemountet wurde. Starten Sie neu und führen Sie den Befehl erneut aus, und geben Sie diesmal TestFS.mount an anstatt den Platzhalter zu verwenden. Die Ergebnisse für dieses Mount stimmen jetzt damit überein, dass es beim Start gemountet wird:
[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.
Eine Reittiereinheit erstellen
Einhängeeinheiten können entweder mit dem traditionellen /etc/fstab konfiguriert werden Datei oder mit systemd-Einheiten. Fedora verwendet die fstab Datei, wie sie während der Installation erstellt wird. However, systemd uses the systemd-fstab-generator program to translate the fstab file into systemd units for each entry in the fstab Datei. 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 Linie. Now, create a new file with the name TestFS.mount in the /etc/systemd/system Verzeichnis. 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 Datei.
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