© phloenphoto, 123RF

Das Initsystem Systemd hat die meisten Rennen gewonnen. Das äußert sich auch darin, dass bereits mehrere Tools eine Bedienung per Mausklick anbieten. Die Bitparade hat sechs davon gestartet.

Der in der Linux-Community anfangs stark umstrittene System- und Prozessmanager Systemd [1] gilt inzwischen als etabliert, das alte Sys-V-Initsystem hat weitgehend ausgedient. Kritiker monieren aber noch immer das binäre Format der Logdateien, den Umstand, dass Systemd für DNS-Anfragen mitunter auf Googles Nameserver zurückgreift, sowie die starke Ausrichtung auf den Gnome-Desktop.

Im Vergleich zum Vorgänger bietet Systemd aber auch Vorteile: Indem es Prozesse parallel startet, verkürzt es das Hochfahren des Betriebssystems vor allem auf Multicore-Rechnern deutlich. Zudem beschleunigt das kompilierte Programm den Prozessablauf.

Systemd-Einmaleins

Die von Systemd verwalteten Prozesse heißen Units. Sie erinnern formal an herkömmliche Ini-Dateien. Dabei erledigen sie unterschiedliche Aufgaben: Sie verwalten Dienste, definieren Einhängepunkte, kümmern sich um den Swap-Speicher oder legen Devices an.

Service-Units, die Dienste verwalten, ähneln den Initskripten von Sys-V-Init oder Upstart. Welche Funktion eine Unit ausübt, verrät ihre Datei-Endung: Während Varianten mit ».service« sich um Dienste kümmern, hängen Units mit ».mount« am Ende beispielsweise Dateisysteme ein. Einheiten mit ».timer«-Endung regeln wiederkehrende Aufgaben und erinnern an Cronjobs, ».device«-Units legen Gerätedateien an.

Eine Ausnahmeposition nehmen ».socket«- und ».target«-Units ein: Während erstere Sockets öffnen, fassen Targets mehrere Units zusammen und ersetzen teilweise auch die von Sys-V-Init bekannten Runlevel.

Auf der Kommandozeile dirigieren Admins die Units mit dem Befehl:

systemctl OptionenKommandos

Er dient unter anderem dazu, die Konfigurationsdateien der entsprechenden Units, die im Textformat vorliegen, zu bearbeiten. Um das zu tun, gibt der Admin am Prompt

systemctl edit --full Unitname

ein. Ebenfalls als Service-Unit von Systemd fungiert Journald, das sich um die Log-Einträge im zentralen Journal kümmert. Der Befehl »journalctl Option« gibt Einsicht in die Logdatei, wobei zahlreiche Parameter für Teilabfragen existieren.

Grafische Tools

Admins konfigurieren, steuern und überwachen Systemd üblicherweise mit Hilfe der Kommandozeile. Doch mit zunehmender Verbreitung des Initsystems gibt es auch immer mehr grafische Tools. Diese variieren im Funktionsumfang deutlich. Benötigt der Admin eine Lösung für seine individuellen Bedürfnisse, sollte er die Kandidaten vor einer Installation daher genauer in Augenschein nehmen (Tabelle 1).

Neben der von Red Hat entwickelten Software Cockpit [2], die teils eine ähnliche Funktionalität aufweist wie Webmin [3] und somit primär zur Serveradministration dient, verwalten inzwischen auch mehrere kleine Projekte Systemd auf Einzelplatzsystemen, wobei sie meist eine spezielle Desktopumgebung voraussetzen. Hierzu gehören der Systemd System Manager im Paket »systemd-gui« beziehungsweise »systemd-ui«[4], wobei es sich um eine auf dem GTK+-Toolkit basierende Oberfläche handelt.

Daneben gibt es den Systemd Manager [5] mit GTK-3-Oberfläche sowie Kcmsystemd [6], das auf dem KDE-Desktop und anderen auf Qt-Bibliotheken basierenden Arbeitsumgebungen zu Hause ist. Eine Weiterentwicklung dieser Software heißt Systemd-KCM [7]. Sie benötigt in der aktuellen Variante KDEs Plasma 5 als Desktopumgebung und läuft unter älteren KDE-Varianten nicht. Seit Kurzem heißt das ursprüngliche KDE-Konfigurationsmodul Systemd Genie [8] und existiert als eigenständige Applikation.

Neben diesen Desktop-spezifischen gibt es noch Applikationen wie beispielsweise Gnome Logs [9], das jedoch mit Journald nur einen Teilbereich von Systemd betreut und daher kein vollwertiges Managementwerkzeug darstellt.

Die einzelnen Applikationen integrieren sich unterschiedlich in den Desktop: Während die Tools für GTK-basierte Systeme größtenteils als eigenständige Applikation arbeiten, fügen sich die KDE-Varianten bis auf das neue Systemd Genie als einzelne Module in das Kontrollzentrum des Desktops ein.

Ein Vorteil ist, dass die User auch die Systemd-Komponenten über eine einheitliche Oberfläche konfigurieren und ihr System nicht über mehrere Anwendungen mit teils unterschiedlichen Bedienkonzepten verwalten müssen. Verwirrung stiftet aber die Namensgebung: So verbirgt sich hinter dem Paket »systemd-gui« in Linux Mint und Ubuntu (»systemd-ui« in Debian) der Systemd System Manager [4], den Unerfahrene leicht mit dem Systemd Manager [5] verwechseln.

Kcmsystemd

Für den KDE-Desktop in Version 4.x integriert sich Kcmsystemd [6] (die ersten drei Buchstaben stehen dabei für KConfig Module) nahtlos in die Verwaltungstools der Arbeitsoberfläche. Installiert der Anwender das Paket gleichen Namens, stößt er im Bereich »Systemverwaltung« des Frontends »Die Arbeitsumgebung konfigurieren« auf den »Systemd«-Starter. Ein Mausklick auf ihn öffnet ein Listenfenster mit mehreren horizontal angeordneten Reitern darüber. Die machen deutlich, dass sich Kcmsystemd als allumfassende Lösung zum Verwalten von Systemd versteht (Abbildung 1).

Abbildung 1: Die grafische Oberfläche von Kcmsystemd zeigt sich übersichtlich, hat aber dennoch eine ganze Reihe von Bedienelementen im Gepäck.

Der Start aktiviert den Reiter »Units« im linken Bereich. Er listet alle Units namentlich auf und versieht sie mit einer aktuellen Statusanzeige. Voreingestellt sind ausschließlich aktive Units. Setzt der Admin ein Häkchen vor die Option »Show inactive«, sieht er auch inaktive Einheiten. Da ihre Zahl üblicherweise mehrere Hundert Einträge umfasst, hilft ihm zudem ein Suchfeld beim Aufspüren der gewünschten Unit.

Die Liste mit Units zeigt zu jedem Eintrag den »Load State«, »Active State«, den »Unit State« sowie den Namen des Prozesses an. Sie verrät zudem, ob das System die jeweilige Unit geladen und aktiviert hat, und gibt den aktuellen Status an. Klickt der User mit der Maus auf einen beliebigen Prozess, erscheinen unterhalb der Liste Detailangaben.

Über die Schaltflächen »Anhalten« und »Restart« stoppt der Admin einzelne Units oder startet sie neu. Dies funktioniert allerdings nicht bei allen Einträgen: Device-Dateien, mit deren Hilfe Systemd angeschlossene Geräte verwaltet, kann er nicht anhalten oder neu starten. Bei solchen Units graut die Software die entsprechenden Steuerfelder aus.

Überfährt der User die einzelnen Units mit der Maus, erscheinen in temporär aufklappenden Fenstern die Abhängigkeiten der Unit von anderen. Dadurch sieht er sofort, welche anderen Einheiten eine Unit parallel anfordert (»Requires:«) oder zwingend voraussetzt (»After:«) und welche Systemd unabhängig von anderen Units zwingend parallel starten soll (»Wants:«). Insbesondere bei komplexen Targets helfen diese Informationen Probleme mit dem Initsystem zu beheben (Abbildung 2).

Abbildung 2: Informationen über das Zusammenspiel mehrerer Units zeigt bei Kcmsystemd ein Kasten (blau hinterlegt) bei der Anzeige von Prozessen.

Ein Rechtsklick auf einen beliebigen Prozess öffnet ein Kontextmenü, das – je nach Art der Unit – unterschiedliche Optionen bereitstellt. Bei Problemen schaltet der Admin darüber bestimmte Dienste ab (»Disable Unit«). Unabhängig von der Art des Prozesses bearbeitet er mit Ausnahme der Geräte-Units auch die entsprechenden Konfigurationsdateien.

Dazu klickt er im Kontextmenü auf die Option »Edit Unit File« und authentifiziert sich im Anschluss als Administrator. Dies öffnet den Texteditor Kwrite mit der entsprechenden Konfigurationsdatei für die markierte Unit, die sich nun problemlos bearbeiten lässt (Abbildung 3).

Abbildung 3: Konfigurationsdateien lassen sich problemlos bearbeiten.

Damit die Modifikationen Gültigkeit erlangen, startet er die Unit im Anschluss neu. Kryptische Startskripte und der Einsatz eines Shellinterpreters gehören bei Systemd der Vergangenheit an.

Die rechts vom Reiter »Units« stehenden Tabs »Systemd«, »Voreinstellungen«, »Journald« und »Logind« widmen sich nicht der Konfiguration der einzelnen Prozesse und Targets, sondern kümmern sich darum, Systemd selbst, die Protokollierung sowie die Anmeldung und Sitzungsverwaltung anzupassen.

Das Loggingsystem Journald passt der Admin hingegen separat an. Zu den Einstelloptionen der vier Reiter gehören neben Pfadangaben zur Ablage der Journale sowie zu deren Größe auch CPU-spezifische Angaben. So weist der Anwender beispielsweise im Reiter »Systemd« in den »Advanced Settings« CPU-Ressourcen fest zu oder nimmt auch bestimmte Hardware-abhängige Einstellungen vor (Abbildung 4). Die Sitzungsverwaltung »Logind« umfasst auch Einstellungen zu Systemzuständen wie beispielsweise zum Powermanagement oder den virtuellen Terminals.

Abbildung 4: Die Protokollfunktion passen Interessierte mit Kcmsystemd sehr feingranular an.

Die Modifikationen schreibt der Admin mit Hilfe der Schaltfläche »Anwenden« unten rechts im Einstellungsfenster in das Verzeichnis »/etc/systemd«. Den Schreibvorgang stößt die Software erst nach einer Authentifizierung über ein gesondertes Fenster an.

Systemd System Manager

Der für GTK-Arbeitsoberflächen konzipierte Systemd System Manager [4] kommt mit einer sehr schlicht gehaltenen Oberfläche daher, die auch weit weniger Konfigurations- und Informationsoptionen bietet als Kcmsystemd. Nach der Installation des Pakets »systemd-ui« wartet in seiner Menüstruktur der Eintrag »systemadm« auf den User.

Die Oberfläche von Systemd System Manager listet in ihrem Hauptfenster ebenso wie die KDE-Pendants die vorhandenen aktiven Units inklusive ihrer Zustände auf. Auch hier schaltet der Admin bei Bedarf inaktive Units per Häkchen zu. Über das Auswahlfeld »All unit types« wählt er bestimmte Unit-Typen aus und bekommt so die zahlreichen Units des Systems in den Griff. Unterhalb des Listenbereichs zeigt das Programmfenster zudem tiefergehende Informationen zu markierten Einheiten an. Anders als Kcmsystemd fehlt dem Systemd System Manager jedoch die Option, einzelne Units über ein Kontextmenü zu bearbeiten und ihre Konfigurationsdateien zu modifizieren (Abbildung 5).

Abbildung 5: Das Programmfenster vom Systemd System Manager bietet weniger Optionen als Kcmsystemd.

Bestehende Abhängigkeiten zeigt dieser Manager im unteren Bereich des Programmfensters an und verwendet dabei unterschiedliche Farben: In grüner Farbe erscheinen korrekt geladene und aktive Einheiten, rot eingefärbte Units sind abgestürzt oder wurden vom System aus anderen Gründen nicht geladen. Mit Hilfe der darunter befindlichen Buttons »Start«, »Stop«, »Restart« und »Reload« aktiviert und stoppt der Anwender die Units entsprechend.

Über die Schaltfläche »Take Snapshot« oben rechts friert der Admin das System in einem definierten Zustand ein. Alternativ stellt er mit dem Button »Reload Configuration« einen vorherigen Systemzustand wieder her, wodurch das System etwa deaktivierte Dienste neu lädt.

Die Journalfunktion oder die Sitzungsverwaltung passt der Systemd System Manager nicht an. Hierzu muss der Admin aufs Terminal.

Systemd Manager

Das noch recht junge Projekt Systemd Manager [5] ist ebenfalls für GTK+-basierte Arbeitsoberflächen konzipiert, allerdings in der Version 3. Zudem steckt die in Mozillas Programmiersprache Rust [10] geschriebene Software bislang ausschließlich in den Standardrepositories des russischen Rosa Linux und von Arch Linux. Für Fedora stellt der Entwickler ein eigenes Archiv bereit. Für Debian wartet ein für 64-Bit-Hardware gedachtes Debian-Paket, das auch problemlos unter Ubuntu und Linux Mint läuft. Die Github-Seite enthält zudem Quellcode zur manuellen Übersetzung.

Der Systemd Manager präsentiert eine übersichtliche, zweigeteilte Oberfläche: Während links im Fenster die einzelnen Units mit zwei Statusanzeigen »Enabled« und »Active« erscheinen, zeigt das rechte Areal die Konfigurationsdateien zu den jeweiligen Units. Über dem rechten Fenstersegment befinden sich zudem die Reiter »File«, »Journal« und »Dependencies«. Während »File« in der Voreinstellung aktiv ist und die Konfigurationsdatei anzeigt, präsentiert »Journal« die Journaleinträge der jeweiligen Unit. »Dependencies« visualisiert die bestehenden Abhängigkeiten in Baumform.

Über den beiden Segmenten befindet sich noch eine Zeile mit Angaben über den jeweiligen Dienst. Den startet und stoppt der Admin bequem über die beiden Schaltflächen »Stop« und »Start« rechts im Fenster. Links daneben schaltet er die aktuelle Unit durch den Schieberegler »Enabled:« beim Systemstart ein oder aus (Abbildung 6).

Abbildung 6: Sehr übersichtlich präsentiert sich die Oberfläche des Systemd Manager.

Doch Systemd Manager zeigt nicht alle von Systemd angelegten Unit-Kategorien an: Im oberen Bereich des Programmfensters befindet sich voreingestellt die Option »Services«. Alternativ wählt der Admin hier »Sockets« und »Timers« aus. Weitere erwartbare Kategorien wie etwa »Targets« oder »Devices« unterstützt das Programm nicht (Abbildung 7).

Abbildung 7: Die wichtigsten Unit-Typen, wenn auch nicht alle, zeigt System Manager per Auswahlfeld an. Das bringt auch die zugehörigen Journaleinträge auf den Schirm.

Modifikationen

Der Systemd Manager gestattet eine einfache Modifikation der vorhandenen Konfigurationsdateien: Hat der Anwender eine Unit markiert und sieht rechts im Fenster im Reiter »File« die zugehörige Konfigurationsdatei, schreibt er einfach in diese hinein und nimmt dort seine Änderungen vor. Danach klickt er auf »Save« unterhalb des rechten Fensterbereichs, um die Konfigurationsdatei zu sichern und zu nutzen.

Analyse

Klickt der Anwender oben links im Programmfenster auf den vorgegebenen Eintrag »Systemd Units«, startet er eine Analyse der geladenen Dienste, indem er im sich öffnenden Auswahlfeld die Option »Systemd Analyze« wählt. Der Systemd Manager ändert dann die Fensteransicht, wobei links die allgemeinen Ladezeiten für das System in Sekunden erscheinen, während er rechts die Ladezeiten für die einzelnen Units aufführt. Hier erfasst er auf einen Blick, welche Dienste besonders lange brauchen (Abbildung 8).

Abbildung 8: Renner und Penner beim Systemstart ermittelt der Admin beim Systemd Manager einfach per Mausklick.

Systemd-KCM

Speziell für KDEs Plasma 5 eignet sich das Konfigurationsmodul Systemd-KCM [7], das sich wie sein Vorgänger für den KDE-4.x-Desktop nahtlos in die Einstellungsdialoge der Arbeitsoberfläche einfügt. Auch Systemd-KCM landet bei den gängigen Distributionen nicht automatisch mit auf der Festplatte, der Anwender muss es separat einspielen.

Etwas Ärger macht dabei das Namens-Tohuwabohu: Während das Modul bei Arch Linux und Open Mandriva als »systemd-kcm« auftritt, heißt es bei Rosa-Linux-Distributionen »plasma5-systemd-kcm« und bei Kubuntu »kde-config-systemd«.

Die Oberfläche weicht dagegen auf den ersten Blick kaum vom Modul für KDE 4.x ab: Auch Systemd-KCM öffnet ein Programmfenster mit einem großen, mit mehreren Reitern gegliederten Anzeigebereich, der nur wenige Bedienelemente aufweist. Erst bei genauerem Hinsehen wird deutlich, dass die Reiterstruktur von der des Vorgängers abweicht: Einstelloptionen für die Sitzungs- und Login-Verwaltung fehlen nun, die Reiter »Benutzereinheiten«, »Einrichtung«, »Sitzungen« und »Zeitmesser« tauchen neu auf (Abbildung 9).

Abbildung 9: Systemd-KCM zeigt eine ähnliche Oberfläche wie Kcmsystemd, bringt jedoch einige geänderte Optionen mit.

Die »Benutzereinheiten« bezeichnen dabei Units, die auf Benutzerebene aktiv sind, während der erste Reiter »Einheiten« sämtliche System-Units auflistet. Der Funktionsumfang dieser beiden Fenster ist identisch mit dem der oben erwähnten Vorgänger.

Im dritten Reiter – »Einrichtung«, in der englischsprachigen Variante heißt er schlicht »Conf« – konfiguriert der Admin die einzelnen Systemd-Bestandteile. Er bestimmt oben rechts in einem Auswahlfeld, ob er die Datei »system.conf«, »journald.conf« oder »logind.conf« bearbeiten möchte. In Tabellenform erscheinen dann unterhalb die einzelnen Parameter der gewählten Konfigurationsdatei, die sich bearbeiten lassen. Auch hier erscheinen beim Drüberfahren mit dem Mauszeiger Hinweise zu den einzelnen Optionen (Abbildung 10).

Abbildung 10: Die Parameter der Konfigurationsdateien lassen sich mit einer Eingabe im Programmfenster ändern.

Modifikationen stellt Systemd-KCM in fetter Schrift dar, sodass der User sich einen schnellen Überblick über die Änderungen verschafft. Um diese in der jeweiligen Datei zu sichern, verwendet er unten rechts den Button »Anwenden« und muss sich anschließend authentifizieren, da die Software ohne Rootrechte aus den konventionellen KDE-Systemeinstellungen startet.

Der »Sitzungen«-Tab verwaltet die Logind-Einstellungen. Er zeigt sämtliche Logind-Sitzungen an, die der Admin per Rechtsklick aktiviert, beendet oder sperrt. Im letzten Reiter »Zeitmesser« erhält der Anwender einen detaillierten Überblick über die vorhandenen Timer-Units. Diese tauchen zwar bereits im ersten Reiter auf, wenn der Admin aus der Auswahlliste der Units die Option »Zeitmesser« auswählt, doch die Darstellung im eigenen Reiter ist deutlich aussagekräftiger. Hier erscheinen nicht nur die Timer-Units selbst namentlich (wobei Systemd-KCM System- wie auch User-Timer aufführt), sondern auch die genauen Zeiten der letzten und der nächsten Ausführung. Außerdem taucht die jeweils aktivierte Service-Unit in der Tabelle auf.

Systemd Genie

Das erst kurz vor Weihnachten 2016 in einer ersten Version freigegebene Systemd Genie [8] stellt faktisch eine von den KDE-Systemeinstellungen ausgekoppelte Variante von Systemd-KCM dar. Die Software ist bislang mit Ausnahme von Gentoo Linux [11] ausschließlich im Quellcode [12] zu haben und bringt nach dem Kompilieren als Stand-alone-Applikation die gleichen Funktionen und eine bis ins Detail zu Systemd-KCM identische Tabstruktur. Einen Unterschied zeigen lediglich eine Menüleiste und eine Buttonleiste mit einigen häufig genutzten Funktionen wie dem Starten, Stoppen und Neuladen der jeweiligen Units.

Grundvoraussetzung für den Einsatz von Systemd Genie sind die Qt-Bibliotheken ab Version 5.4, auf älteren KDE-Varianten läuft Systemd Genie nicht. Eine kurze Installationsanleitung stellt der Entwickler unter [13] bereit.

Cockpit

Das Cockpit-Projekt [2] schreibt sich in erster Linie das Servermanagement auf die Fahnen, bietet dabei jedoch aufgrund der engen Verquickung mit Systemd auch die Möglichkeit, den Sitzungsmanager auf dem Zielsystem zu administrieren. Bereits Mitte 2015 beschäftigte sich das Linux-Magazin mit dem Projekt, der zugehörige Artikel beschreibt die ältere Cockpit-Version 0.27 [14]. Aktuell ist die Version 126 – die Major-Nummer davor nutzen die Entwickler inzwischen offenbar nicht mehr.

Red Hat pflegt und entwickelt die Software weiter und setzt Systemd zwingend voraus. Fertige Pakete und Repositories stehen für Fedora Server, Centos, Red Hat Enterprise Linux sowie RHEL Atomic bereit. Daneben findet sich die Applikation in eigenen Repositories für Debian und Ubuntu, während Arch Linux eine inoffizielle Unterstützung erfährt [15]. Fedora Server installiert das Programm sogar ab Werk vor. Zusätzlich stellen die Entwickler auf Github den Quellcode der unter der LGPL stehenden Software bereit [16].

Fehlstart

Bei der Testinstallation der aktuellen Cockpit-Version 126 fiel zunächst ein Defizit auf: Leider haben es die Projektentwickler versäumt, im Falle von Ubuntu die genauen Systemspezifikationen für den Einsatz von Cockpit darzulegen. Wollen Anwender das Programm mit Hilfe des offiziellen Archivs in Ubuntu 16.10 installieren, integriert sich das vorhandene PPA-Archiv nicht in das System, da es für Ubuntu 16.04 gedacht ist. Die Installation auf der etwas älteren, aber mit Langzeitunterstützung versehenen Ubuntu-Variante gelingt problemlos über die drei Schritte in Listing 1.

01 sudo add-apt-repository ppa:cockpit-project/cockpit
02 sudo apt-get update
03 sudo apt-get install cockpit

Am Ende startet der Anwender noch den Systemd-Socket, was über

sudo systemctl enable --now cockpit.socket

recht mühelos gelingt. Ab sofort ist die Software einsatzbereit, ihre Oberfläche erscheint im Webbrowser des Intranets, wenn der Admin »https://IP-Adresse-des- Servers:9090« in die Adressleiste eintippt. Cockpit nutzt – mit Ausnahme der Installation auf dem Server selbst – ausschließlich mit SSL/TLS gesicherte Verbindungen, wobei es beim ersten Start ein selbst signiertes Zertifikat anlegt.

Kommt jedoch keine Verbindung zustande, liegt dies vermutlich an einer Blockade des Ports 9090 durch die Firewall. Den Port muss der Anwender freischalten, Fedora Server erledigt dies übrigens bereits von Hause aus.

Danach erscheint das Cockpit-Dashboard mit dem Login-Bildschirm im Browser. Der Admin authentifiziert sich und gelangt so in den Startbildschirm. Hier warten links Auswahllisten für verschiedene Aufgaben, rechts erscheinen die zugehörigen Inhalte in einem großen Bereich (Abbildung 11). Um Systemd-Prozesse auf dem Server zu konfigurieren und zu verwalten, wählt der Admin den Eintrag »Services« links im Auswahlbereich. Die Software listet die vorhandenen Prozesse und Dienste in Tabellenform auf, wobei Cockpit zunächst alle Typen berücksichtigt, auch die inaktiven.

Abbildung 11: Red Hats Cockpit bringt ein übersichtliches Dashboard mit.

Weitere im Intranet auffindbare Server verwaltet der Cockpit-User, indem er im Hauptfenster oben auf »Dashboard« klickt und ganz rechts in der vertikalen Mitte des Fensters den Button »+« bedient. Nun lässt sich der neu zu integrierende Server über seine IP-Adresse in Cockpit einbinden. Die Verwaltungssoftware meldet sich dann mit den Authentifizierungsdaten des Anwenders beim neuen Server an und holt die nötigten Informationen von ihm. Danach taucht der Server unter seiner IP-Adresse in der Liste der Serversysteme auf, die im unteren Bereich des Fensters wartet. Dort ruft der User per Klick auf einen der Server dessen Leistungsdaten ab.

Die Systemd-Units erreicht er auch hier Geräte-abhängig über den Menüpunkt »Services« links im Dashboard. Cockpit unterteilt die Liste in die Kategorien »Enabled«, »Disabled« und »Static«, was der Übersicht dient. Zudem warten am oberen Rand der Listenansicht die Schaltflächen »Targets«, »System Services«, »Sockets«, »Timers« und »Paths«, über die der User sehr schnell einzelne Units identifiziert (Abbildung 12).

Abbildung 12: Cockpit zeigt alle Units in dreispaltigen Tabellen an.

Unabhängig vom Betriebsstatus einer Unit landet der Anwender nach einem Klick auf diese in einem Log-Fenster, das ihm das Log der jeweiligen Unit anzeigt. Das spart langwierige Suchen nach einzelnen Log-Einträgen im Journal.

Manager

Um in Cockpit Prozesse und Daemons zu verwalten, muss sich der Anwender zuvor mit Administratorrechten bei der Software anmelden. Wahlweise startet er im Dashboard über »Tools | Terminal« in einem eingeblendeten Terminal neue Prozesse. Alternativ wählt er per Mausklick die gewünschte Unit aus einer Liste aus. Im Anschluss sieht er nicht nur die Log-Einträge der Unit, sondern auch weitere Angaben inklusive des Pfades.

Zwei Auswahlfelder rechts im Fenster stellen die verschiedensten Funktionen per Mausklick bereit: Über diese aktiviert, deaktiviert oder lädt der Administrator Systemd-Units neu. Auch einen zwangsweisen Start einer Unit ermöglichen sie. Über das integrierte Terminal modifiziert der Anwender zusätzlich die Konfigurationsdatei. Alles in allem macht das ein sehr einfaches Management der Systemd-Prozesse mit Cockpit möglich (Abbildung 13).

Abbildung 13: Im Journalfenster startet der Cockpit-User Units neu oder deaktiviert diese.

Fazit

Die grafischen Tools für Systemd genügen verschiedensten Ansprüchen und erleichtern die Arbeit mit Prozessen und Diensten enorm. Dem Anwender genügen grundlegende Kenntnisse über Systemd, um seine Sitzungen zu steuern. Er muss nicht im Vorfeld kryptische Parameter auswendig lernen.

Bei vielen der noch jungen Projekte fehlt allerdings noch eine einführende Dokumentation, die weitere Optionen und Einstellmöglichkeiten jenseits der meist tabellarischen Unit-Listen erläutert. Dieses Manko fällt insbesondere bei Kcmsystemd auf. Hier konfiguriert der Nutzer zwar – wie bei KDE üblich – alles bis ins kleinste Detail, manche technischen Eigenheiten der Journald- und Logind-Optionen sollte die Software ihm jedoch besser erklären.

Die GTK-basierten Applikationen Systemd System Manager und Systemd Manager zeigen sich im direkten Vergleich zu den Qt-basierten Tools deutlich rudimentärer und beschränken sich auf die grundlegenden Verwaltungsaufgaben. Sie eignen sich eher für das gelegentliche Ab- und Einschalten von Prozessen.

Cockpit, das im Browser genutzte Interface für Admins, fällt ein wenig aus der Rolle. Es ist weniger als Administrationstool für lokale Systeme gedacht, sondern vereinfacht und zentralisiert im Intranet die komplette Serververwaltung. Dabei bietet das Werkzeug einen sehr einfachen Zugang zu Systemd auf den jeweiligen Servern und erlaubt es dem Administrator, von jedem Arbeitsplatz aus die Dienste und Prozesse des Initsystem zu verwalten (kki).