SystemD ist ein Systemverwaltungstool, das verwendet wird, um Systemverwaltungsaufgaben zu rationalisieren und die Effizienz zu verbessern. Sein Hauptvorteil liegt in seiner Fähigkeit, die Systemleistung und Reaktionsfähigkeit sowie die Sicherheit zu verbessern, indem automatisch nach Schwachstellen gesucht und diese gepatcht werden.
Darüber hinaus kann SystemD dazu beitragen, Systemressourcen effektiver zu organisieren, sodass Programme schneller und reibungsloser ausgeführt werden können. Alles in allem ist SystemD die ideale Lösung, wenn Sie nach einem effektiven Systemverwaltungstool suchen, mit dem Sie das Beste aus Ihrem System herausholen können. In diesem Artikel erfahren Sie alles, was Sie über SystemD wissen müssen.
Wofür wird SystemD verwendet?
SystemD ist ein Systemverwaltungstool, das für eine Vielzahl von Aufgaben verwendet werden kann, von der Verwaltung von Systemressourcen und -prozessen bis hin zur Optimierung der Systemleistung auf Linux-Systemen. Es wird aufgrund seiner leistungsstarken Fähigkeiten und fortschrittlichen Funktionen in vielen verschiedenen Branchen eingesetzt, vom Gesundheitswesen bis zur Fertigung.
Ganz gleich, ob Sie große Server oder kleinere Workstations betreiben, SystemD bietet eine Reihe von Vorteilen, mit denen Sie die Systemeffizienz und -produktivität verbessern können. Zu den wichtigsten Funktionen gehören Prozesspriorisierung, Systemereignisprotokollierung und Steuerung der Systemressourcenzuweisung. Wenn Ihre Organisation also nach einem zuverlässigen Systemverwaltungstool sucht, das dabei helfen kann, die Effizienz und Leistung aller Systeme zu steigern, dann ist SystemD definitiv eine Überlegung wert.
Warum mögen Menschen SystemD nicht?
Während viele Benutzer SystemD für ein unschätzbares Systemverwaltungstool halten, gibt es einige, die es aus verschiedenen Gründen nicht mögen. Einige Kritiker argumentieren, dass es zu komplex und schwierig zu verwenden ist, insbesondere für diejenigen, die mit Systemadministrationsaufgaben nicht vertraut sind. Andere behaupten, dass es sich negativ auf die Systemleistung auswirken kann, was zu langsameren Startzeiten und einer erhöhten Ressourcennutzung führt.
Trotz dieser Bedenken bleibt SystemD jedoch eines der am weitesten verbreiteten Systemverwaltungstools auf dem heutigen Markt und wird dies wahrscheinlich auch in Zukunft bleiben. Wenn Sie nach einem effizienten Systemverwaltungstool suchen, mit dem Sie die Produktivität der Systeme Ihres Unternehmens verbessern können, ist SystemD definitiv eine Überlegung wert.
Warum ist SystemD umstritten?
SystemD ist ein äußerst umstrittenes Systemverwaltungstool, hauptsächlich aufgrund der anhaltenden Debatte über seine Effektivität und Benutzerfreundlichkeit. Einige Benutzer behaupten, dass es sich negativ auf die Systemleistung auswirken kann, während andere argumentieren, dass es eine Reihe wichtiger Vorteile bietet, wie z. B. verbesserte Systemsicherheit und effizientere Zuweisung von Systemressourcen.
Es gibt auch Bedenken hinsichtlich der Komplexität und Benutzerfreundlichkeit von SystemD, wobei viele Benutzer die steile Lernkurve und die verwirrende Benutzeroberfläche als Hauptkritikpunkte nennen. Trotz dieser Bedenken bleibt SystemD jedoch eines der am weitesten verbreiteten Systemverwaltungstools auf dem heutigen Markt und wird dies wahrscheinlich auch in Zukunft bleiben. Wenn Sie nach einem leistungsstarken Systemverwaltungstool suchen, mit dem Sie die Systemleistung und -effizienz über alle Systeme hinweg verbessern können, ist SystemD möglicherweise die ideale Lösung für Sie.
Was ist SystemD vs. init?
SystemD und init sind Systemverwaltungstools, die aufgrund ihrer ähnlichen Funktionen und sich überschneidenden Eigenschaften oft verglichen werden. Obwohl beide Systemverwaltungstools für eine Vielzahl von Systemverwaltungsaufgaben verwendet werden können, wie z. B. Prozesspriorisierung, Systemereignisprotokollierung und Steuerung der Systemressourcenzuweisung, gibt es einige wesentliche Unterschiede zwischen ihnen.
Während sich init beispielsweise auf Prozesse zum Starten und Herunterfahren von Systemen konzentriert, bietet SystemD eine breitere Palette von Systemverwaltungsfunktionen. Darüber hinaus finden viele Benutzer SystemD benutzerfreundlicher und intuitiver als init, was es zu einer beliebten Wahl bei Systemadministratoren und IT-Experten macht. Wenn Sie nach einer effektiven Systemverwaltungslösung suchen, mit der Sie die Systemleistung und -effizienz über alle Systeme hinweg verbessern können, ist SystemD möglicherweise die ideale Wahl für Sie.
Soll ich Grub oder SystemD verwenden?
Auf diese Frage gibt es keine endgültige Antwort, da sowohl Grub als auch SystemD ihre eigenen Vor- und Nachteile haben. Einerseits ist Grub ein leichtgewichtiges Systemverwaltungstool, das einfache, optimierte Funktionen zum Starten und Herunterfahren des Systems bietet.
Auf der anderen Seite bietet SystemD eine größere Auswahl an Systemverwaltungsfunktionen und -funktionen, was es zu einem leistungsfähigeren und vielseitigeren Systemverwaltungstool macht. Ob Sie sich letztendlich für Grub oder SystemD entscheiden, hängt von Ihren spezifischen Bedürfnissen und Vorlieben als Systemadministrator oder IT-Experte ab. Wenn Sie jedoch nach einer effizienten Systemverwaltungslösung suchen, die dazu beitragen kann, die Systemleistung und -effizienz über alle Systeme hinweg zu verbessern, ist SystemD wahrscheinlich die bessere Wahl.
Wie man SystemD verwendet
Als Nächstes behandeln wir einige Möglichkeiten, wie Sie SystemD auf Linux-Systemen verwenden können. Dies sind nur einige Beispiele, die Sie selbst ausprobieren können. Es dauert einige Zeit, sich an die Syntax zu gewöhnen, aber sobald Sie sie beherrschen, wird SystemD zu einem mächtigen Werkzeug.
SystemD - Init
Dies ist der erste vom Kernel gestartete Prozess und erhält die Prozess-ID 1 . Es verwaltet den Boot-Prozess und Aufgaben wie das Erstellen von Sockets, das Einrichten von Hardware, das Mounten von Festplatten usw.
SystemD arbeitet mit Einheiten unterschiedlichen Typs. Neben dem Dienst selbst gibt es auch:
- Zeitgeber
- anbringen
- Netzwerk
- Buchsen
- Partitionen
- Geräte
Darüber hinaus können Sie mit SystemD auch andere Prozesse verwalten:
- beginnen
- Stopp
- neu starten
- töten
Unit-Dateien
Es gibt verschiedene Pfade für vorhandene Unit-Dateien:
| Pfad | Informationen |
|---|---|
| /usr/lib/systemd/system | vordefinierte SystemD-Dateien (nicht ändern) |
| /etc/systemd/system | Speicherort für benutzerdefinierte Einheitendateien |
| /run/systemd/system | Für die laufzeitrelevanten Dateien |
Wichtige Informationen zu den Pfaden: SystemD bevorzugt immer /etc/ gegenüber /usr/lib/ . Aus diesem Grund platzieren wir dort benutzerdefinierte Unit-Dateien.
Sie können die Unit-Datei eines bestimmten Dienstes besuchen, indem Sie den Pfad besuchen oder mit dem Befehl:
systemctl cat <service>
Code language: Bash (bash)Beispiel:OpenVPN:
[email protected]:~$ systemctl cat openvpn
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Wie wir in der Unit-Datei sehen können, definieren Sie, welcher Pfad verwendet wird , die PID-Datei und weitere Optionen . Worauf wir weiter unten näher eingehen werden. Wir können alle verfügbaren Eigenschaften mit den Optionen anzeigen, die in der Unit-Datei für den Dienst definiert werden können, indem wir den Befehl verwenden:
systemctl show <service>
Code language: Bash (bash)Hier sind zum Beispiel wieder die ersten Zeilen der Ausgabe von OpenVPN:
[email protected]:~$ systemctl show openvpn
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=n/a
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainStartTimestampMonotonic=9823235
ExecMainExitTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainExitTimestampMonotonic=9824084
ExecMainPID=1164
ExecMainCode=1
ExecMainStatus=0v
Code language: Bash (bash)Wenn wir nun die Unit-Datei des Dienstes bearbeiten wollen, führen wir den Befehl aus:
systemctl edit – full <service>
Code language: Bash (bash)
Wenn wir den Befehl ohne full ausführen Option erhalten wir eine leere Datei. Wir haben die Möglichkeit, eine Kopie der Quelldatei zu erstellen, die wir bearbeiten können.
Stellen wir uns als Beispiel für eine mögliche Option vor, wir möchten, dass OpenVPN immer läuft. Selbst wenn der Prozess gestoppt oder beendet wird, möchten wir, dass er von selbst neu startet.
Wir öffnen den Editor und fügen die spezifische Option hinzu:
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Restart=yes
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Danach müssen wir die Konfigurationsdatei neu laden:
systemctl reload <service>
Code language: Bash (bash)Starten Sie schließlich den Dienst neu:
systemctl restart <service>
Code language: Bash (bash)Mit diesem Befehl versucht SystemD, den Dienst neu zu laden. Wenn dies nicht funktioniert, wird der Dienst neu gestartet:
systemctl reload-or-restart <service>
Code language: HTML, XML (xml)In den obigen Befehlen haben wir gelernt, wie man Dienste manuell steuert. Mit SystemD können Sie auch Dienste dauerhaft aktivieren oder deaktivieren, sodass sie entweder automatisch bei Bedarf gestartet werden oder gar nicht verfügbar sind. Die folgende Tabelle zeigt die verfügbaren Befehle:
| Befehl | Funktion |
|---|---|
| aktivieren | Aktiviert einen Dienst |
| deaktivieren | Deaktiviert einen Dienst |
| ist aktiviert | Überprüfen Sie, ob ein Dienst aktiviert ist |
| erneut aktivieren | deaktiviert einen Dienst und aktiviert ihn dann wieder |
| Maske | Wenn Sie einen Dienst vollständig deaktivieren möchten, maskieren Sie ihn - Seien Sie vorsichtig |
| demaskieren | demaskiert einen Dienst |
Anwendungsbeispiel:
systemctl enable <service>
Code language: Bash (bash)Ziele
Dies sind verschiedene Zustände, in denen das System booten kann.
SystemD fügt ein neues Konzept für die bekannten Runlevel hinzu. Das ältere Prinzip wird jedoch beibehalten. Nur die Runlevel erhalten Namen statt Nummern:
| Ziel | Effekt |
|---|---|
| halt.ziel | System herunterfahren |
| poweroff.target | Fahrt das System physisch herunter (Ausschalten) |
| rescue.target | Einzelbenutzermodus |
| multi-user.target | Mehrbenutzermodus |
| Grafik.Ziel | Mehrbenutzermodus mit grafischer Oberfläche |
| reboot.target | Startet das System neu |
Sie können mit dem folgenden Befehl zu einem anderen Ziel wechseln:
systemctl isolate example.target
Code language: Bash (bash)Starten Sie das System neu:
systemctl reboot
Code language: Bash (bash)Versetzt das System in einen Tiefschlaf und hält alle laufenden Prozesse an:
systemctl hybrid-sleep
Code language: Bash (bash)Schaltet das System mit einer Broadcast-Nachricht an alle angemeldeten Benutzer aus:
systemctl shutdown
Sie können dies ändern, indem Sie die Parameter verwenden:
systemctl shutdown -r now
Code language: Bash (bash)Dies würde das System neu starten (-r) und die Broadcast-Nachricht umgehen und direkt neu starten. Es gibt viele verschiedene Parameter, um diesen Befehl zu verwenden. Sie können sie auf der Manpage nachschlagen.
Mit dem folgenden Befehl können Sie das aktuelle Ziel anzeigen, in das das System bootet:
systemctl get-default
Code language: Bash (bash)Außerdem können Sie das Ziel ändern:
systemctl set-default example.target
Code language: Bash (bash)Die verschiedenen Runlevel können auch hier eingesehen werden:
ls -la /usr/lib/systemd/system |grep runle*
Code language: Bash (bash)[email protected]:~$ ls -la /usr/lib/systemd/system |grep runle*
lrwxrwxrwx 1 root root 15 Apr 18 22:12 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel1.target -> rescue.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel1.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel2.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel2.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel3.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel3.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel4.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel4.target.wants
lrwxrwxrwx 1 root root 16 Apr 18 22:12 runlevel5.target -> graphical.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel5.target.wants
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel6.target -> reboot.target
-rw-r--r – 1 root root 803 Apr 18 22:12 systemd-update-utmp-runlevel.service
Code language: plaintext (plaintext)Kontrollgruppen
SystemD organisiert Tasks in Kontrollgruppen. Dies wird für die Ressourcenkontrolle in Linux verwendet und ermöglicht es, verfügbare Ressourcen beschränken zu können , priorisiert , gezählt, und isoliert .
Die folgenden Befehle sind daher sehr nützlich, um die Systemleistung zu analysieren und zu optimieren:
systemd-analyze
Code language: Bash (bash)Dieser Befehl kann verwendet werden, um die Startleistung zu ermitteln.
[email protected]:~$ systemd-analyze
Startup finished in 12.712s (firmware) + 328ms (loader) + 8.240s (kernel) + 6.634s (userspace) = 27.916s
graphical.target reached after 6.631s in userspace
Code language: plaintext (plaintext)Wie wir sehen können, erhalten wir eine Aufschlüsselung der Zeiten, wie lange es dauert, bis jede Aufgabe gestartet wird.
Mit dem zusätzlichen Befehl blame wir erhalten eine sehr detaillierte Liste, wie lange welcher einzelne Prozess zum Starten benötigt:
systemd-analyze blame
Ausgabe :
[email protected]:~$ systemd-analyze blame
5.573s NetworkManager-wait-online.service
3.244s plymouth-quit-wait.service
2.285s fwupd.service
467ms logrotate.service
392ms lm-sensors.service
385ms accounts-daemon.service
362ms snapd.service
290ms systemd-resolved.service
279ms networkd-dispatcher.service
247ms networking.service
213ms dev-nvme0n1p3.device
182ms apparmor.service
178ms ModemManager.service
174ms systemd-journal-flush.service
168ms udisks2.service
161ms NetworkManager.service
152ms com.system76.Scheduler.service
128ms apport.service
127ms e2scrub_reap.service
116ms rsyslog.service
115ms smartmontools.service
114ms wpa_supplicant.service
105ms [email protected]
100ms gpu-manager.service
....
Code language: plaintext (plaintext)Wenn wir alle Kontrollgruppen sehen wollen, können wir verwenden:
systemd-cgls
Code language: Bash (bash)oder
systemctl status
Code language: Bash (bash)Wir erhalten eine baumbasierte Ausgabe mit allen notwendigen Informationen:
[email protected]:~$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─[email protected]
│ │ ├─session.slice
│ │ │ ├─dbus-broker.service
│ │ │ │ ├─3119 /usr/bin/dbus-broker-launch – scope user
│ │ │ │ └─3120 dbus-broker – log 4 – controller 10 – machine-id 04d8535513777afc7bb291c362dd90a7 – max-bytes 100000000000000 – max-fds 25000000000000 – max-matches 50000000>
│ │ │ ├─xdg-document-portal.service
│ │ │ │ ├─3761 /usr/libexec/xdg-document-portal
│ │ │ │ └─3773 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal – /run/user/1000/doc
│ │ │ ├─xdg-desktop-portal.service
│ │ │ │ └─3753 /usr/libexec/xdg-desktop-portal
│ │ │ ├─pipewire-pulse.service
│ │ │ │ └─3112 /usr/bin/pipewire-pulse
│ │ │ ├─wireplumber.service
│ │ │ │ └─3111 /usr/bin/wireplumber
│ │ │ ├─plasma-xdg-desktop-portal-kde.service
│ │ │ │ └─3861 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
│ │ │ └─pipewire.service
│ │ │ └─3106 /usr/bin/pipewire
│ │ ├─background.slice
│ │ │ ├─plasma-kactivitymanagerd.service
│ │ │ │ └─3546 /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd
│ │ │ ├─plasma-kscreen.service
│ │ │ │ └─3610 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
│ │ │ ├─plasma-baloorunner.service
│ │ │ │ └─5633 /usr/lib/x86_64-linux-gnu/libexec/baloorunner
│ │ │ ├─plasma-kglobalaccel.service
│ │ │ │ └─3452 /usr/bin/kglobalaccel5
│ │ │ └─tracker-miner-fs-3.service
│ │ │ └─3148 /usr/libexec/tracker-miner-fs-3
│ │ ├─app.slice
│ │ │ ├─app-\\x2fusr\\x2fbin\\x2fkorgac-d27ecb9065d646918a10df1c4fa798fe.scope
│ │ │ │ └─3599 /usr/bin/korgac -session 10dfe2702d000165869202400000083140007_1663442587_18526
│ │ │ ├─gvfs-goa-volume-monitor.service
│ │ │ │ └─3171 /usr/libexec/gvfs-goa-volume-monitor
│ │ │ ├─app-dbus\\x2d:1.2\\x2dorg.gnome.OnlineAccounts.slice
│ │ │ │ └─dbus-:[email protected]
│ │ │ │ └─3174 /usr/libexec/goa-daemon
│ │ │ ├─xdg-permission-store.service
│ │ │ │ └─3765 /usr/libexec/xdg-permission-store
│ │ │ ├─com.system76.SystemUpdater.Local.service
Code language: plaintext (plaintext)
Mit der systemd-cgtop Befehl erhalten wir eine Liste aller Kontrollgruppen, sortiert nach der aktuellen Ressourcenauslastung:
systemd-cgtop
Code language: Bash (bash)Nun, warum ist uns das wichtig? Jetzt können wir die Ressourcenauslastung einzelner Prozesse analysieren und ggf. die Priorität des Prozesses anpassen oder das Ressourcenlimit ändern.
Die Manpage gibt uns viele Möglichkeiten, dies zu verwalten:
man systemd.resource-control
Code language: Bash (bash)Wenn wir zum Beispiel das Speicherlimit eines bestimmten Dienstes festlegen möchten, können wir Folgendes verwenden:
systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)Protokollierung - JournalD
JournalD protokolliert alle Ereignisse im RAM des Systems. Dies wird bei einem Systemneustart gelöscht.
Sie können JournalD mit dem folgenden Befehl verwenden:
journalctl
Code language: Bash (bash)Wir können die Ausgabe weiter verfeinern, indem wir Filter hinzufügen, zum Beispiel mit einer bestimmten Zeit:
journalctl – since yesterday
Code language: Bash (bash)Wir können es noch weiter verfeinern, indem wir einen genauen Zeitraum von bis angeben:
journalctl – since "date" – until "date"
Code language: Bash (bash)Eine andere Möglichkeit zum Filtern besteht darin, bestimmten Diensten zu folgen:
journalctl -u example
Code language: Bash (bash)Wir können auch einem bestimmten Dienst folgen und nur nach diesem filtern:
journalctl -fu example
Code language: Bash (bash)Wir könnten auch nur nach Kernel-Events filtern:
journalctl -k
Code language: Bash (bash)Zusammenfassung
SystemD ist ein starker Nachfolger des klassischen System V-Init-Daemons und stellt dem Administrator viele nützliche Informationen und Tools zur Verfügung, die die tägliche Arbeit und den Arbeitsablauf beschleunigen. Wenn Sie mehr über andere eingehende Linux-Themen erfahren möchten, besuchen Sie unbedingt den Blog von Max Wilke.
- SystemD ist ein Systemverwaltungstool, das für Aufgaben wie die Verwaltung von Systemressourcen verwendet werden kann und Prozesse , Optimierung der Systemleistung und Verbesserung der Sicherheit .
- SystemD bietet eine Reihe von Vorteilen, die Organisationen dabei helfen können, Effizienz und Produktivität zu verbessern , einschließlich Prozesspriorisierung , Systemereignisprotokollierung und Steuerelemente für die Ressourcenzuweisung .
- Obwohl SystemD aufgrund seiner leistungsstarken Fähigkeiten in vielen verschiedenen Branchen weit verbreitet ist, einige Benutzer es nicht mögen, weil es komplex oder schwierig zu verwenden ist . Darüber hinaus argumentieren einige Kritiker, dass es die Systemleistung negativ beeinflussen kann .
- Trotz dieser Bedenken bleibt SystemD heute eines der beliebtesten Systemverwaltungstools auf dem Markt.