In Systemd lieben lernen , dem ersten Artikel dieser Serie, habe ich die Funktionen und Architektur von systemd und die Kontroverse um seine Rolle als Ersatz für das alte SystemV-Init-Programm und die Startskripte betrachtet. In diesem zweiten Artikel beginne ich damit, die Dateien und Tools zu untersuchen, die die Linux-Startsequenz verwalten. Ich werde die Startsequenz von systemd erklären, wie man das standardmäßige Startziel (Runlevel in SystemV-Begriffen) ändert und wie man manuell zu einem anderen Ziel wechselt, ohne einen Neustart zu durchlaufen.
Ich werde mir auch zwei wichtige systemd-Tools ansehen. Das erste ist das systemctl Befehl, der das primäre Mittel zur Interaktion mit und zum Senden von Befehlen an systemd ist. Das zweite ist journalctl , das Zugriff auf die systemd-Journale bietet, die riesige Mengen an Systemverlaufsdaten wie Kernel- und Dienstmeldungen (sowohl Informations- als auch Fehlermeldungen) enthalten.
Stellen Sie sicher, dass Sie in diesem und zukünftigen Artikeln ein Nicht-Produktionssystem zum Testen und Experimentieren verwenden. Auf Ihrem Testsystem muss ein GUI-Desktop (wie Xfce, LXDE, Gnome, KDE oder andere) installiert sein.
Ich habe in meinem vorherigen Artikel geschrieben, dass ich vorhabe, eine systemd-Unit zu erstellen und sie der Startsequenz in diesem Artikel hinzuzufügen. Da dieser Artikel länger geworden ist, als ich erwartet hatte, werde ich das für den nächsten Artikel in dieser Serie zurückbehalten.
Linux-Startup mit systemd erkunden
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
Bevor Sie die Startsequenz beobachten können, müssen Sie einige Dinge tun, um die Boot- und Startsequenzen zu öffnen und sichtbar zu machen. Normalerweise verwenden die meisten Distributionen eine Startanimation oder einen Begrüßungsbildschirm, um die detaillierten Meldungen auszublenden, die sonst während des Startens und Herunterfahrens eines Linux-Hosts angezeigt würden. Dies wird bei Red Hat-basierten Distributionen als Plymouth-Startbildschirm bezeichnet. Diese versteckten Meldungen können einem Systemadministrator, der nach Informationen sucht, um einen Fehler zu beheben oder einfach nur etwas über die Startsequenz zu erfahren, eine Menge Informationen über das Starten und Herunterfahren liefern. Sie können dies mit der GRUB-Konfiguration (Grand Unified Boot Loader) ändern.
Die Hauptkonfigurationsdatei von GRUB ist /boot/grub2/grub.cfg , aber da diese Datei überschrieben werden kann, wenn die Kernel-Version aktualisiert wird, möchten Sie sie nicht ändern. Ändern Sie stattdessen die Datei /etc/default/grub Datei, die verwendet wird, um die Standardeinstellungen von grub.cfg zu ändern .
Sehen Sie sich zunächst die aktuelle, unveränderte Version von /etc/default/grub an Datei:
[root@testvm1 ~]# cd /etc/default; cat grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=gespeichert
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]#
Kapitel 6 der GRUB-Dokumentation enthält eine Liste aller möglichen Einträge in /etc/default/grub Datei, aber ich konzentriere mich auf Folgendes:
- Ich ändere GRUB_TIMEOUT , die Anzahl der Sekunden für den Countdown des GRUB-Menüs, von fünf bis 10, um etwas mehr Zeit zu haben, auf das GRUB-Menü zu reagieren, bevor der Countdown Null erreicht.
- Ich lösche die letzten beiden Parameter auf GRUB_CMDLINE_LINUX , das die Befehlszeilenparameter auflistet, die beim Booten an den Kernel übergeben werden. Einer dieser Parameter ist rhgb steht für Red Hat Graphical Boot und zeigt die kleine Fedora-Icon-Animation während der Kernel-Initialisierung an, anstatt Boot-Meldungen anzuzeigen. Der andere, der ruhige verhindert die Anzeige der Startup-Meldungen, die den Fortschritt des Startups und eventuell auftretende Fehler dokumentieren. Ich lösche beide rhgb und leise weil Systemadministratoren diese Nachrichten sehen müssen. Wenn beim Booten etwas schief geht, können die auf dem Bildschirm angezeigten Meldungen auf die Ursache des Problems hinweisen.
Nachdem Sie diese Änderungen vorgenommen haben, sieht Ihre GRUB-Datei wie folgt aus:
[root@testvm1 default]# cat grub
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=gespeichert
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]#
Die grub2-mkconfig Programm erzeugt die grub.cfg Konfigurationsdatei mit dem Inhalt von /etc/default/grub -Datei, um einige der standardmäßigen GRUB-Einstellungen zu ändern. Die grub2-mkconfig Programm sendet seine Ausgabe an STDOUT . Es hat ein -o Option, mit der Sie eine Datei angeben können, an die der Datenstrom gesendet werden soll, aber es ist genauso einfach, die Umleitung zu verwenden. Führen Sie den folgenden Befehl aus, um /boot/grub2/grub.cfg zu aktualisieren Konfigurationsdatei:
[root@testvm1 grub2]# grub2-mkconfig> /boot/grub2/grub.cfg
Grub-Konfigurationsdatei wird generiert ...
Linux-Image gefunden:/boot/vmlinuz-4.18.9- 200.fc28.x86_64
Initrd-Image gefunden:/boot/initramfs-4.18.9-200.fc28.x86_64.img
Linux-Image gefunden:/boot/vmlinuz-4.17.14-202.fc28. x86_64
Initrd-Image gefunden:/boot/initramfs-4.17.14-202.fc28.x86_64.img
Linux-Image gefunden:/boot/vmlinuz-4.16.3-301.fc28.x86_64
Initrd-Image gefunden:/boot/initramfs-4.16.3-301.fc28.x86_64.img
Linux-Image gefunden:/boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504
Initrd-Image gefunden:/boot/ initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img
fertig
[root@testvm1 grub2]#
Starten Sie Ihr Testsystem neu, um die Startmeldungen anzuzeigen, die sonst hinter der Plymouth-Boot-Animation verborgen wären. Aber was ist, wenn Sie die Startmeldungen anzeigen müssen und die Plymouth-Boot-Animation nicht deaktiviert haben? Oder Sie haben, aber die Nachrichten strömen zu schnell vorbei, um sie zu lesen? (Was sie tun.)
Es gibt ein paar Optionen, und beide beinhalten Protokolldateien und systemd-Journale – die Ihre Freunde sind. Sie können weniger verwenden Befehl, um den Inhalt von /var/log/messages anzuzeigen Datei. Diese Datei enthält Boot- und Startup-Meldungen sowie Meldungen, die während des normalen Betriebs vom Betriebssystem generiert werden. Sie können auch das journalctl verwenden Befehl ohne Optionen zum Anzeigen des systemd-Journals, das im Wesentlichen dieselben Informationen enthält:
[root@testvm1 grub2]# journalctl
-- Die Protokolle beginnen am Samstag, den 11.01.2020, 21:48:08 Uhr EST, und enden am Freitag, den 03.04.2020, 08:54:30 Uhr EDT. --
11. Januar 21:48:08 Kernel 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 Mo Okt>
Jan 11 21:48:08 f31vm.both.org Kernel:Befehlszeile: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. Januar 21:48:08 Kernel von f31vm.both.org:x86/fpu:Unterstützung von XSAVE-Funktion 0x001:'x87-Gleitkommaregister'
Jan 11 21:48:08 Kernel von f31vm.both.org:x86/fpu:Unterstützung von XSAVE-Funktion 0x002:'SSE registers'
Jan 11 21:48:08 f31vm.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x004:'AVX registers'
Jan 11 21:48:08 f31vm.both. org-Kernel:x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
11. Januar 21:48:08 f31vm.both.org-Kernel:x86/fpu:Aktivierte xstate-Funktionen 0x7, Kontextgröße ist 832 Bytes, im 'Standard'-Format.
11. Januar 21:48:08 f31vm.both.org Kernel:BIOS-provide d physische RAM-Karte:
11. Januar 21:48:08 f31vm.both.org Kernel:BIOS-e820:[mem 0x0000000000000000-0x000000000009fbff] verwendbar
11. Januar 21:48:08 f31vm.both.org Kernel:BIOS-e820:[mem 0x000000000009fc00-0x000000000009ffff] reserviert
Jan 11 21:48:08 f31vm.both.org Kernel:BIOS-e820:[mem 0x00000000000f0000-0x000000000 reserviert 00fff] 1 Jan:1 fff 48:08 f31vm.both.org Kernel:BIOS-e820:[mem 0x0000000000100000-0x00000000dffeffff] verwendbar Daten
11. Januar 21:48:08 f31vm.both.org Kernel:BIOS-e820:[mem 0x00000000fec00000-0x00000000fec00fff] reserviert
11. Januar 21:48:08 f31vm.both.org Kernel:BIOS- e820:[mem 0x00000000fee00000-0x00000000fee00fff] reserviert
Jan 11 21:48:08 f31vm.both.org Kernel:BIOS-e820:[mem 0x00000000fffc0000-0x00000000ffffffff] reserviert
Jan .both.org-Kernel:BIOS-e820:[mem 0x0000000100000000-0x000000041fffffff] nutzbar
11. Januar 2 1:48:08 f31vm.both.org-Kernel:NX (Execute Disable)-Schutz:aktiv
11. Januar 21:48:08 f31vm.both.org-Kernel:SMBIOS 2.5 vorhanden.
11. Januar 21:48:08 f31vm.both.org Kernel:DMI:innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jan 11 21:48:08 f31vm.both.org Kernel:Hypervisor erkannt:KVM
11. Januar 21:48:08 f31vm.both.org Kernel:kvm-clock:Using msrs 4b564d01 und 4b564d00
11. Januar 21:48:08 f31vm.both.org Kernel:kvm-clock:cpu 0, msr 30ae01001, primäre CPU-Uhr
11. Januar 21:48:08 f31vm.both.org Kernel:kvm-clock:Sched-Offset von 8250734066 Zyklen verwenden
11. Januar 21:48:08 f31vm.both.org Kernel :clocksource:kvm-clock:mask:0xffffffffffffffff max_cycles:0x1cd42e4dffb, max_idle_ns:881590591483 ns
Jan 11 21:48:08 f31vm.both.org Kernel:tsc:2807,992 MHz Prozessor erkannt
Jan 21:11 48:08 f31vm.both.org Kernel:e820:Update [mem 0x00000000-0x00000fff] nutzbar ==> reserviert
Jan 11 21:48:08 f31vm.both.org Kernel:e820:entfernen [mem 0x000a000 0-0x000fffff] nutzbar
Ich habe diesen Datenstrom abgeschnitten, weil er Hunderttausende oder sogar Millionen Zeilen lang sein kann. (Die Zeitschriftenliste auf meiner primären Workstation ist 1.188.482 Zeilen lang.) Versuchen Sie dies unbedingt auf Ihrem Testsystem. Wenn es einige Zeit läuft – auch wenn es viele Male neu gestartet wurde – werden riesige Datenmengen angezeigt. Erkunden Sie diese Journaldaten, da sie viele Informationen enthalten, die bei der Problembestimmung sehr nützlich sein können. Wenn Sie wissen, wie diese Daten bei einem normalen Boot- und Startvorgang aussehen, können Sie Probleme leichter lokalisieren, wenn sie auftreten.
Ich werde systemd-Journale, das journalctl, besprechen Befehl, und wie Sie all diese Daten sortieren, um das Gewünschte zu finden, in einem zukünftigen Artikel dieser Serie.
Nachdem GRUB den Kernel in den Speicher geladen hat, muss es sich zuerst selbst aus der komprimierten Version der Datei extrahieren, bevor es nützliche Arbeit leisten kann. Nachdem der Kernel sich selbst extrahiert und gestartet hat, lädt er systemd und übergibt ihm die Kontrolle.
Dies ist das Ende des Bootvorgangs. Zu diesem Zeitpunkt laufen der Linux-Kernel und systemd, können aber keine produktiven Aufgaben für den Endbenutzer ausführen, da nichts anderes ausgeführt wird, es keine Shell gibt, die eine Befehlszeile bereitstellt, keine Hintergrundprozesse zur Verwaltung des Netzwerks oder anderer Kommunikationsverbindungen und nichts, was es dem Computer ermöglicht, produktive Funktionen auszuführen.
Systemd kann nun die Funktionseinheiten laden, die erforderlich sind, um das System in einen ausgewählten Zielbetriebszustand zu bringen.
Ziele
Ein systemd-Ziel repräsentiert den aktuellen oder gewünschten Ausführungszustand eines Linux-Systems. Ähnlich wie SystemV-Startskripte definieren Ziele die Dienste, die vorhanden sein müssen, damit das System in diesem Zustand ausgeführt und aktiv ist. Abbildung 1 zeigt die möglichen Run-State-Ziele eines Linux-Systems mit systemd. Wie im ersten Artikel dieser Serie und in der Manpage systemd bootup (man bootup) zu sehen ist, gibt es weitere Zwischenziele, die erforderlich sind, um verschiedene erforderliche Dienste zu aktivieren. Dazu kann swap.target gehören , timer.target , local-fs.target , und mehr. Einige Ziele (wie basic.target ) werden als Kontrollpunkte verwendet, um sicherzustellen, dass alle erforderlichen Dienste betriebsbereit sind, bevor mit dem Ziel der nächsthöheren Ebene fortgefahren wird.
Sofern nicht beim Booten im GRUB-Menü anders geändert, startet systemd immer das default.target . Das default.target file ist ein symbolischer Link auf die wahre Zieldatei. Bei einer Desktop-Workstation ist dies normalerweise graphical.target , was Runlevel 5 in SystemV entspricht. Für einen Server ist der Standardwert eher multi-user.target , was wie Runlevel 3 in SystemV ist. Das emergency.target Datei ähnelt dem Einzelbenutzermodus. Ziele und Dienste sind systemd-Einheiten.
Die folgende Tabelle, die ich in den vorherigen Artikel dieser Serie eingefügt habe, vergleicht die Systemd-Ziele mit den alten SystemV-Startup-Runlevels. Die systemd-Zielaliase werden von systemd aus Gründen der Abwärtskompatibilität bereitgestellt. Die Ziel-Aliase erlauben Skripten – und Systemadministratoren – die Verwendung von SystemV-Befehlen wie init 3 Runlevel ändern. Natürlich werden die SystemV-Befehle zur Interpretation und Ausführung an systemd weitergeleitet.
| systemd-Ziele | SystemV-Runlevel | Zielaliase | Beschreibung |
| default.target | Diesem Ziel wird immer ein Alias mit einem symbolischen Link zu entweder multi-user.target zugewiesen oder graphical.target . systemd verwendet immer das default.target um das System zu starten. Das default.target sollte niemals zu halt.target aliased werden , poweroff.target oder reboot.target . | ||
| Grafik.Ziel | 5 | runlevel5.ziel | Multi-user.target mit einer GUI |
| 4 | runlevel4.ziel | Unbenutzt. Runlevel 4 war identisch mit Runlevel 3 in der SystemV-Welt. Dieses Ziel kann erstellt und angepasst werden, um lokale Dienste zu starten, ohne das standardmäßige multi-user.target zu ändern . | |
| multi-user.target | 3 | runlevel3.ziel | Alle Dienste laufen, aber nur Befehlszeilenschnittstelle (CLI) |
| 2 | runlevel2.ziel | Mehrbenutzer, ohne NFS, aber alle anderen Nicht-GUI-Dienste laufen | |
| rescue.target | 1 | runlevel1.ziel | Ein einfaches System, einschließlich des Mountens der Dateisysteme, wobei nur die grundlegendsten Dienste ausgeführt werden, und eine Notfall-Shell auf der Hauptkonsole |
| emergency.target | S | Einzelbenutzermodus – es werden keine Dienste ausgeführt; Dateisysteme werden nicht gemountet. Dies ist die grundlegendste Betriebsebene, bei der nur eine Notfall-Shell auf der Hauptkonsole ausgeführt wird, damit der Benutzer mit dem System interagieren kann. | |
| halt.ziel | Hält das System an, ohne es herunterzufahren | ||
| reboot.target | 6 | runlevel6.ziel | Neu starten |
| poweroff.target | 0 | runlevel0.ziel | Hält das System an und schaltet den Strom aus |
Jedes Ziel hat eine Reihe von Abhängigkeiten, die in seiner Konfigurationsdatei beschrieben sind. systemd startet die erforderlichen Abhängigkeiten, bei denen es sich um die Dienste handelt, die erforderlich sind, um den Linux-Host auf einer bestimmten Funktionalitätsebene auszuführen. Wenn alle in den Zielkonfigurationsdateien aufgeführten Abhängigkeiten geladen sind und ausgeführt werden, wird das System auf dieser Zielebene ausgeführt. Wenn Sie möchten, können Sie sich die systemd-Startsequenz und die Laufzeitziele im ersten Artikel dieser Reihe, Systemd lieben lernen, ansehen .
Das aktuelle Ziel erkunden
Viele Linux-Distributionen installieren standardmäßig eine GUI-Desktop-Oberfläche, damit die installierten Systeme als Workstations verwendet werden können. Ich installiere immer von einem Fedora Live-Boot-USB-Laufwerk mit einem Xfce- oder LXDE-Desktop. Selbst wenn ich einen Server oder einen anderen Infrastruktur-Host installiere (wie die, die ich für Router und Firewalls verwende), verwende ich eine dieser Installationen, die einen GUI-Desktop installiert.
Ich könnte einen Server ohne Desktop installieren (und das wäre typisch für Rechenzentren), aber das entspricht nicht meinen Anforderungen. Es ist nicht so, dass ich den GUI-Desktop selbst benötige, aber die LXDE-Installation enthält viele der anderen Tools, die ich verwende, die nicht in einer Standard-Serverinstallation enthalten sind. Das bedeutet weniger Arbeit für mich nach der Erstinstallation.
Aber nur weil ich einen GUI-Desktop habe, bedeutet das nicht, dass es sinnvoll ist, ihn zu verwenden. Ich habe einen 16-Port-KVM, mit dem ich auf die KVM-Schnittstellen der meisten meiner Linux-Systeme zugreifen kann, aber die überwiegende Mehrheit meiner Interaktion mit ihnen erfolgt über eine Remote-SSH-Verbindung von meiner primären Workstation. Diese Methode ist sicherer und verbraucht weniger Systemressourcen, um multi-user.target auszuführen im Vergleich zu graphical.target.
Überprüfen Sie zunächst das Standardziel, um sicherzustellen, dass es sich um graphical.target handelt :
[root@testvm1 ~]# systemctl get-default
graphical.target
[root@testvm1 ~]#
Überprüfen Sie nun das aktuell ausgeführte Ziel. Es sollte mit dem Standardziel identisch sein. Sie können weiterhin die alte Methode verwenden, die die alten SystemV-Runlevel anzeigt. Beachten Sie, dass sich der vorherige Runlevel auf der linken Seite befindet; es ist N (was None bedeutet), was darauf hinweist, dass sich der Runlevel seit dem Booten des Hosts nicht geändert hat. Die Zahl 5 gibt das aktuelle Ziel an, wie es in der alten SystemV-Terminologie definiert ist:
[root@testvm1 ~]# Runlevel
N 5
[root@testvm1 ~]#
Beachten Sie, dass die Runlevel-Manpage darauf hinweist, dass Runlevel veraltet sind, und eine Konvertierungstabelle bereitstellt.
Sie können auch die systemd-Methode verwenden. Hier gibt es keine einzeilige Antwort, aber sie liefert die Antwort in systemd-Begriffen:
[root@testvm1 ~]# systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target geladen aktiv aktiv Basissystem
aktiv aktiv Load load Verschlüsselte Volumes
getty.target geladen aktiv aktiv Anmeldeaufforderungen
graphical.target geladen aktiv aktiv grafische Benutzeroberfläche
local-fs-pre.target geladen aktiv aktiv Lokale Dateisysteme (Pre)
local-fs.target geladen aktiv aktiv Lokale Dateisysteme
multi-user.target geladen aktiv aktiv Mehrbenutzersystem
network-online.target geladen aktiv aktiv Netzwerk ist online
network.target geladen aktiv aktiv Netzwerk
nfs-client.target geladen aktiv aktiv NFS-Client-Dienste
nss-user-lookup.target geladen aktiv aktiv Suche nach Benutzer- und Gruppennamen
paths.target geladene aktive aktive Pfade
remote-fs-pre.target geladene aktive aktive Remote-Dateisysteme (Pre)
remote-fs.target geladene aktive aktive Remote-Dateisysteme
rpc_pipefs.target geladene aktive aktive rpc_pipefs .Target
Slices.target geladene aktive aktive scheiben
aktiv Swap
sysinit.target geladen aktiv aktiv Systeminitialisierung
timers.target geladen aktiv aktiv Timer
LOAD =Gibt an, ob die Einheitendefinition richtig geladen wurde.
ACTIVE =Der Aktivierungszustand der Einheit auf hoher Ebene, d. h. Verallgemeinerung von SUB.
SUB =Der Aktivierungszustand der Einheit auf niedriger Ebene, die Werte hängen vom Einheitentyp ab.
21 geladene Einheiten aufgelistet. Übergeben Sie --all, um auch geladene, aber inaktive Units zu sehen.
Um alle installierten Unit-Dateien anzuzeigen, verwenden Sie 'systemctl list-unit-files'.
Hier werden alle derzeit geladenen und aktiven Ziele angezeigt. Sie können auch das graphical.target sehen und das multi-user.target . Das multi-user.target ist vor graphical.target erforderlich geladen werden können. In diesem Beispiel das graphical.target ist aktiv.
Wechseln zu einem anderen Ziel
Den Wechsel zum multi-user.target vornehmen ist einfach:
[root@testvm1 ~]# systemctl isolate multi-user.target Die Anzeige sollte nun vom GUI-Desktop oder Anmeldebildschirm zu einer virtuellen Konsole wechseln. Melden Sie sich an und listen Sie die derzeit aktiven systemd-Einheiten auf, um dieses graphical.target zu überprüfen läuft nicht mehr:
[root@testvm1 ~]# systemctl list-units --type target Achten Sie darauf, den Runlevel zu verwenden Befehl, um zu überprüfen, ob sowohl vorherige als auch aktuelle "Runlevels" angezeigt werden:
[root@testvm1 ~]# Runlevel
5 3
Ändern des Standardziels
Ändern Sie nun das Standardziel in multi-user.target damit es immer in das multi-user.target bootet für eine Konsolen-Befehlszeilenschnittstelle und nicht für eine GUI-Desktopschnittstelle. Wechseln Sie als Root-Benutzer auf Ihrem Testhost in das Verzeichnis, in dem die systemd-Konfiguration verwaltet wird, und führen Sie eine schnelle Auflistung durch:
[root@testvm1 ~]# cd /etc/systemd/system/; ll
drwxr-xr-x. 2 root root 4096 25. April 2018 basic.target.wants
lrwxrwxrwx. 1 root root 36 Aug 13 16:23 default.target -> /lib/systemd/system/graphical.target
lrwxrwxrwx. 1 root root 39 25. April 2018 display-manager.service -> /usr/lib/systemd/system/lightdm.service
drwxr-xr-x. 2 root root 4096 25. April 2018 getty.target.wants
drwxr-xr-x. 2 root root 4096 18. August 10:16 graphical.target.wants
drwxr-xr-x. 2 root root 4096 25. April 2018 local-fs.target.wants
drwxr-xr-x. 2 root root 4096 30. Okt 16:54 multi-user.target.wants
[root@testvm1 system]#
Ich habe diese Auflistung gekürzt, um einige wichtige Dinge hervorzuheben, die erklären, wie systemd den Startvorgang verwaltet. Sie sollten die gesamte Liste der Verzeichnisse und Links auf Ihrer virtuellen Maschine sehen können.
Das default.target entry ist ein symbolischer Link (Symlink, Softlink) auf das Verzeichnis /lib/systemd/system/graphical.target . Listen Sie dieses Verzeichnis auf, um zu sehen, was es sonst noch gibt:
[root@testvm1 system]# ll /lib/systemd/system/ | less Sie sollten Dateien, Verzeichnisse und weitere Links in dieser Auflistung sehen, aber suchen Sie speziell nach multi-user.target und graphical.target . Zeigen Sie nun den Inhalt von default.target an , was ein Link zu /lib/systemd/system/graphical.target ist :
[root@testvm1 system]# cat default.target
# SPDX-Lizenz-ID:LGPL-2.1+
#
# Diese Datei ist Teil von systemd.
#
# systemd ist freie Software; Sie können es weiterverbreiten und/oder modifizieren
# unter den Bedingungen der GNU Lesser General Public License, veröffentlicht von
# der Free Software Foundation; entweder Version 2.1 der Lizenz oder
# (nach Ihrer Wahl) eine spätere 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
[root@testvm1 system]#
Dieser Link zum graphical.target -Datei beschreibt alle Voraussetzungen und Anforderungen, die die grafische Benutzeroberfläche erfordert. Ich werde zumindest einige dieser Optionen im nächsten Artikel dieser Serie untersuchen.
Damit der Host im Mehrbenutzermodus booten kann, müssen Sie den vorhandenen Link löschen und einen neuen erstellen, der auf das richtige Ziel verweist. Erstellen Sie die PWD /etc/systemd/system , falls noch nicht geschehen:
[root@testvm1 system]# rm -f default.target
[root@testvm1 system]# ln -s /lib/systemd/system/multi-user.target default.target
Listen Sie default.target auf Link, um zu überprüfen, ob er auf die richtige Datei verweist:
[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]#
Wenn Ihr Link nicht genau so aussieht, löschen Sie ihn und versuchen Sie es erneut. Listen Sie den Inhalt von default.target auf Link:
[root@testvm1 system]# cat default.target
# SPDX-Lizenz-ID:LGPL-2.1+
#
# Diese Datei ist Teil von systemd.
#
# systemd ist freie Software; Sie können es weiterverbreiten und/oder modifizieren
# unter den Bedingungen der GNU Lesser General Public License, veröffentlicht von
# der Free Software Foundation; entweder Version 2.1 der Lizenz oder
# (nach Ihrer Wahl) eine spätere Version.
[Unit]
Description=Multi-User System
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]#
Das default.target – was eigentlich ein Link zu multi-user.target ist an dieser Stelle – hat jetzt andere Anforderungen in der [Einheit] Sektion. Der grafische Display-Manager ist nicht erforderlich.
Neustart. Ihre virtuelle Maschine sollte mit dem Konsolen-Login für die virtuelle Konsole 1 booten, die auf dem Display als tty1 identifiziert wird. Da Sie nun wissen, wie Sie das Standardziel ändern, ändern Sie es wieder in graphical.target mit einem für diesen Zweck entwickelten Befehl.
Überprüfen Sie zuerst das aktuelle Standardziel:
[root@testvm1 ~]# systemctl get-default
multi-user.target
[root@testvm1 ~]# systemctl set-default graphic.target
Entfernt /etc/systemd /system/default.target.
Symlink erstellt /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.
[root@testvm1 ~]#Geben Sie den folgenden Befehl ein, um direkt zu graphical.target zu wechseln und die Anmeldeseite des Display-Managers ohne Neustart:
[root@testvm1 system]# systemctl isolate default.targetIch weiß nicht, warum die Entwickler von systemd den Begriff „isolate“ für diesen Unterbefehl gewählt haben. Meine Recherchen deuten darauf hin, dass es sich möglicherweise darauf bezieht, das angegebene Ziel auszuführen, aber alle anderen Ziele zu "isolieren" und zu beenden, die nicht zur Unterstützung des Ziels erforderlich sind. Der Effekt besteht jedoch darin, Ziele von einem Ausführungsziel zu einem anderen zu wechseln – in diesem Fall vom Multi-User-Ziel zum grafischen Ziel. Der obige Befehl entspricht dem alten init 5-Befehl in SystemV-Startskripten und dem init-Programm.
Melden Sie sich beim GUI-Desktop an und vergewissern Sie sich, dass es ordnungsgemäß funktioniert.
Zusammenfassung
Dieser Artikel untersuchte die Startsequenz von Linux systemd und begann mit der Untersuchung von zwei wichtigen systemd-Tools, systemctl und journalctl . Außerdem wurde erklärt, wie man von einem Ziel zu einem anderen wechselt und das Standardziel ändert.
Der nächste Artikel in dieser Serie erstellt eine neue systemd-Unit und konfiguriert sie so, dass sie während des Starts ausgeführt wird. Es wird auch einige der Konfigurationsoptionen betrachten, die dabei helfen zu bestimmen, wo in der Sequenz eine bestimmte Einheit startet, zum Beispiel nachdem das Netzwerk eingerichtet und ausgeführt wurde.
Ressourcen
Es gibt eine Menge Informationen über systemd im Internet, aber vieles ist knapp, stumpf oder sogar irreführend. Zusätzlich zu den in diesem Artikel erwähnten Ressourcen bieten die folgenden Webseiten detailliertere und zuverlässigere Informationen zum Systemstart.
- Das Fedora-Projekt hat eine gute, praktische Anleitung zu systemd. Es enthält so ziemlich alles, was Sie wissen müssen, um einen Fedora-Computer mit systemd zu konfigurieren, zu verwalten und zu warten.
- Das Fedora-Projekt hat auch einen guten Spickzettel, der die alten SystemV-Befehle mit vergleichbaren Systemd-Befehlen vergleicht.
- Detaillierte technische Informationen über systemd und die Gründe für seine Erstellung finden Sie in der Beschreibung von systemd auf Freedesktop.org.
- Linux.com's "More systemd fun" bietet weiterführende Informationen und Tipps zu systemd.
Es gibt auch eine Reihe von sehr technischen Artikeln für Linux-Systemadministratoren von Lennart Poettering, dem Designer und Hauptentwickler von systemd. Diese Artikel wurden zwischen April 2010 und September 2011 geschrieben, sind aber heute genauso aktuell wie damals. Vieles von allem anderen Guten, das über systemd und sein Ökosystem geschrieben wurde, basiert auf diesen Papieren.
- Überdenken von PID 1
- systemd für Administratoren, Teil I
- systemd für Administratoren, Teil II
- systemd für Administratoren, Teil III
- systemd für Administratoren, Teil IV
- systemd für Administratoren, Teil V
- systemd für Administratoren, Teil VI
- systemd für Administratoren, Teil VII
- systemd für Administratoren, Teil VIII
- systemd für Administratoren, Teil IX
- systemd für Administratoren, Teil X
- systemd für Administratoren, Teil XI