Benutzer:Dings

Aus wiki.archlinux.de

Dieser Artikel oder Artikelabschnitt ist noch nicht vollständig!

Systemd ist ein System- und Dienstemanager für Linux und kompatibel mit SysV und LSB init Scripts. Systemd stellt offensive Einsatzmöglichkeiten zur Parallelisierung bereit, nutzt socket und D-Bus Aktivierung um Dienste zu starten. Systemd bietet die Möglichkeit Daemons 'on-demand' /auf Anforderung/auf Wunsch zSu starten. Mit Hilfe von Linux cgroups behält Systemd Prozesse im Auge /beobachtet. :


Installation

Um systemd unter Arch nutzen zu können bedarf es folgender Schritte

  • Installation von systemd und seiner Ab

hängigkeiten aus [core] 

# pacman -S systemd
  • Hinzufügen von init=/bin/systemed in die Kernelzeile des Bootloaders.

Systemd kann parallel zu den regulären Archlinux Initscripts installiert werden und mittels hinzufügen/entfernen des init=/bin/systemd Kernelparameters aktiviert bzW. deaktiviert werden. Möchte man ein reines systemd setup verwenden, entfernt man initscripts und installiert systemd-sysvcompat.Sytemd-sysvcompat liefert symlinks für init, reboot usw. . Beim Verwenden des reinen systmd setups braucht das <code<init= parameteter in der Kernelzeile nicht gesetzt zu werden. Vorlage:Warnung

Konfigurationsdateien

Hostnamen hinzufügen

Der Hostname wird in /etc/hostname eingetragen. 

/etc/hostname
meinhostname

Konsolen- und Keymapeinstellungen

Einstellungen für die virtuelle Konsole, wie z.B. das Tastaturlayout und die in der Konsole verwandte Schriftrt werden in der /etc/vconsole.conf Datei vorgenommen 

/etc/vconsole.conf

KEYMAP=de-latin1-nodeadkeys
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

„Locale“ Einstellungen

Genauere Informationen hierzu findet man in der entsprechenden manpage man locale.conf 

/etc/locale.conf
Lang=en_US.UTF-8
LC_COLLATE=C

Festlegen der Zeitzone

/etc/timezone
Europe/Lummerland

Hinweis: Auch wenn man /etc/timzone verwendet wird trotzdem /etc/localtime benötigt!

Kernelmodule für laden während des Bootens konfigurieren

Während des bootens verwendet systemed in /etc/modules-load.d/ abgelegte Konfigurationsdateien. Jede Konfigurationsdatei muss nach dem Schema /etc/modules-load.d/<program>.conf benannt werden. Die Konfigurationsdateien sollen eine einfache Liste der Namen der zu ladenden Kernelmodule beinhalten, jedes Modul in eingetragen in eine separate Zeile. Leerzeilen und Zeilen deren erstes Zeichen ein # oder ; ist, werden ignoriert. Beispiel: 

/etc/modules-load.d/virtio-net.conf

# Laedt virtio-net.ko beim Booten
virtio-net

Siehe Modprobe#Options.

Kernelmodule ausschließen / blacklist

Das Erstellen einer schwarzen Liste für Kernelmodule kann in gleicher Weise Weise wie bei initscripts vorgenommen, da eigentich kmod die Listen verarbeitet. Für Details siehe auch Module Blacklisting. 

BEISPIEL EINFÜGEN

Temporäre Dateien

Systemed-tmpfiles verwendet in /etc/tmpfiles.d/ abgelegte Konfigurationsdateien um erstellen, säubern und entfernen temporärer Dateien, die sich normalerweise in normalerweise in Verzeichnissen wie /run oder /tmp befinden. Jede Konfigurationsdatei in /etc/tmpfiles.d wird nach dem Schema /etc/tmpfiles.d/<program>.conf benannt. Konfigurationsdateien in /etc/tmpfiles.d/ heben die Wirkung gleichnamiger Dateien in /usr/lib/tmpfiles.d/ auf! Tmpfiles werden normalerweise zusammen mit Servicedateien bereitgestellt, um Verzeichnisse zu erstellen deren Existenz von verschiedenen Daemonen erwartet wird. Beispielsweise erwartet der Sambadaemon, dass das Verzeichnis /var/run/samba existiert und mit den passenden Rechten versehen ist. Die entsprechende Tmpdatei sähe dann so aus: 

/usr/lib/tmpfiles.d/samba.conf
D /var/run/samba 0755 root root

Tmpdateien können jedoch auch genutzt werden, um beim Booten Werte in bestimmte Dateien zu schreiben. Nutzt man beispielsweise /etc/rc.local um via echo USBE > /proc/acpi/wakeup wakeup durch USB-Geräte zu deaktivieren, kann man stattdessen folgendes tmpfile benutzen: 

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

Die Methode mit tmpfiles wird empfohlen, da systemd /etc/rc.local nicht untertützt. Unter man tmpfiles.d sind detaillierte Informationen zu finden.

Systemd Journal

Seit Version 38 verfügt systemd über ein eigenes loggingsystem, das sogenannte Journal. Standardmäßig ist es daher nicht länger erforderlich einen syslogdaemon laufen zu lassen. Lesen kann man das Journal/Log durch absetzen von 

# journalctl

Das Journal schreibt in run/systemd/journal, was bedeutet das nach einem reboot die logs gelöscht sind. Um die logs dauerhaft zu bewahren, legt man das Verzeichnis /var/log/journal/ an: 

# mkdir /var/log/journal

Journald im Zusammenhang mit einem klassischen syslogdaemon

Die Kompatiblität mit klassischen syslog Implementierungen wird über einen socket /run/systemd/journal/syslog, an den alle Nachrichten weitergeleitet werden, gewährleistet. Damit der syslogdaemon mit dem journal arbeitet, muss es anstatt an /dev/log/ an /run/systemd/journal/syslog gebunden werden.(Offizielle Bekanntmachung hierzu). Für die Nutzung von syslog-ng ändert man den source Abschnitt in /etc/syslog-ng/syslog-ng.conf folgendermassen ab 

source src {
   unix-dgram("/run/systemd/journal/syslog");
   internal();
   file("/proc/kmsg");
};

und aktiviert (oder reaktiviert) syslog-ng: 

# systemctl enable syslog-ng.service
. Standardmäßig ist journald so konfiguriert, dass es aus /proc/kmsg liest, dies kollidiert allerdings mit einer syslog Implementierung, die das selbe tut systemd-devel post. Man deaktiviert das systemd-journald aus /proc/kmsg liest, indem man 
ImportKernel=0

in die /etc/systemd/journald.conf einträgt.

Netzwerk

Dynamisch (DHCP)

Nutzt man für seine Ethernetverbindung lediglich DHCP, kann man dhcpcd@.service aus dem systemd-arch-units Paket verwenden. Man aktiviert DHCP für eth0 indem man einfach 

# systemctl start dhcpcd@eth0.service

absetzt. Damit der Service automatisch beim Booten gestartet wird, führt man 

# systemctl enable dhcpcd@.service

aus.

Hinweis: Hierdurch wird der Service standardmäßig für eth0 aktiviert

Möchte man ein anderes interface benutzen, muss man den symlink händisch erstellen, z.B.: 

# ln -s '/usr/lib/systemd/system/dhcpcd@.service' '/etc/systemd/system/multi-user.target.wants/dhcpcd@eth1.service'

Andere Konfigurationen

Um statisches, wireless oder erweitertes Netzwerk wie z.B. bridging zu konfigurieren, kann man netcfg oder NetworkManager benutzen. Beide stellen systemd service files bereit. Benötigt man zwar eine statische Netzwerkkonfiguration, möchte aber nicht netcfg benutzen, so findet man auf der Systemd/Services Seite eine angepasste Service Datei.

Remote filesystem mounts

Hat man NFS mounts in die /etc/fstab eingetragen, so wird systemd versuchen diese zu mounten. Leider wird dieser Mountversuch in der Regel zu früh unternommen, bevor das Netzwerk konfiguriert wurde. Um hier eine Zeitabstimmung zu erreichen muss systemd in Abhängigkeit vom Netzwerk und rpc.statd den Mountvorgang anstossen. Dies erreicht man indem man die Datei /etc/systemd/system/<mount-unit-name>.mount mit folgendem Inhalt 

[Unit]
Description=<mountpoint>
Wants=rpc-statd.service
After=network.target rpc-statd.service 

[Mount]
What=<server>:<share>
Where=<mountpoint>
Type=nfs

erstellt. Im einzelnen bedeutet das Obige 

*mount-unit-name ist der volle Pfad zum Einhängepunkt (Mountpoint) im „escaped“-Format. Z.B.: mount unit für /usr/local muss als usr-local.mount benannt werden.
 *mountpoint ist der lokale Einhängepunkt (Mountpoint)
*server:share definiert das remote filesystem in der gleichen Art wie man es in der /etc/fstab tut.

systemd.unit(5) und systemd.mount(5) liefern weitere Details 

man 5 systemd.unit
man 5 systemd.mount

Bei anderen remote filesystem Typen, wie ntfs4 und cifs ist die Vorgehensweise ähnlich. Alternativ kann man diese Einträge auch in etc/fstab mit den x-systemd.automount und x-systemd.device-timeout=# Optionen vornehmen (siehe systemd.mount(5). Es ist hierbei sicherzustellen, dass falls auch defaults als Mountoption verwendet wird, das eingeschlossene auto mit noauto ersetzt wird. Hierdurch wird das Gerät beim ersten Zugriff eingehängt, ähnlich wie Autofs.

Systemd verwenden

*sytemctl: wird verwendet um den Zustand des systemd System und Service Managers zu prüfen und zu kontrollieren.
*systemd-cgls: zeigt rekursiv die Inhalte der gewählten Linux Control Group Hirarchie als Baumschema.
*systemadm ist ein grafisches Frontend für den Systemd System und Service Manager. Es ermöglicht prüfen und kontrollieren von systemd. (Erhältlich über das systemd-ui-git Paket aus dem AUR.)

Wie immer finden sich in den man-pages weitere detaillieter Informationen.

Laufende Services anzeigen: 

$ systemctl

oder 

$ systemctl list-units

Verfügbare Services oder Units können in /usr/lib/systemd/system/ und /etc/systemd/system/(wobei letztere ersteren gegenüber Vorrang haben) eingesehen werden. Einen Service mit sofortiger Wirkung aktivieren: 

# systemctl start <service>

Einen Service mit sofortiger Wirkung deaktivieren: 

# systemctl stop <service>

Einen Service neustarten: 

# systemctl restart <service>

Die Konfiguration eines Services erneut laden 

# systemctl reload <service>

Den Status eines Services anzeigen, einschliesslich ob er gerade läuft oder nicht 

#systemctl status <service>

Prüfen ob ein Service bereits aktiviert ist: 

# systemctl is-enabled <service>

Aktivieren das ein Service bereits während des Bootens gestartet wird: 

# systemctl enable <service>

Deaktivieren das ein Service bereits während des Bootens gestartet wird 

# systemctl disable <service>

Hier man systemctl für weitere Details zu Rate ziehen.

Hinweis: Beachten das man den vollständigen names eines servicefiles verwendet.

Um beispielsweise den avahi-daemon neu zu starten verwendet man: 

# systemctl restart avahi-daemon.service

Fehlgeschlagene Services auflisten: 

# systemctl --failed

Das System herunterfahren und neu starten: 

# systemctl reboot

Das System herunterfahren und anhalten 

#systemctl halt

Das System herunterfahren und ausschalten 

# systemctl poweroff

Das System in den Standbymodus versetzen 

# systemctl suspend

Das System in den Ruhezustand versetzen 

# systemctl hibernate

Runlevels/targets

Runlevels ist ein Vererbungskonzept in systemd. Systemd bedient sich sogenannter targets welche dem gleichen Zweck wie Runlevels dienen, sich aber etwas anders verhalten. Jedes target wird mit einem Namen anstatt einer (wie bei den Runlevels üblich) Nummer versehen und ist dafür vorgesehen einem spezifischen Zweck zu dienen, die Möglichkeit beinhaltend dass verschiedene targets zur gleichen Zeit ktiv sein können. Manche targets werden ausgeführt indem sie alle services eines anderen targets übernehmen und weitere services hinzufügen. Es gibt systemd targets welche herkömmliche SystemVinit runlevels imitieren, so dass man immernoch mittels des gewohnten telinit RUNLEVEL-Befehls zwischen targets umschalten kann.

Den aktuellen Runlevel / aktuelles Target ermitteln

Unter systemd sollte 

# systemctl list-units --type=target

anstelle von runlevel verwendet werden.

Erstellen eigener Targets

Die Runlevels die in „vanilla” Fedora (?!?) Installationen einem bestimmten Zweck zugeschrieben sind (0,1,3,5 und 6) haben ein 1:1 Abbild mit einem spezifischen systemd target. Unglücklicherweise gibt es keine adäquate Möglichkeit den selben Zustand für nutzerdefinierte Runlevel wie 2 und 4 herzustellen. Sollte man solche verwenden wird dazu geraten ein neu benanntes systemd target nach dem Schema /etc/systemd/system/<mein target> auf der Basis eines existierenden Runlevels (als Beispiel kann man /usr/lib/systemd/graphical.target heranziehen) zu erstellen. Anschliessend erstellt man ein Verzeichnis /etc/systemd/system/<mein target>.wants und verlinkt (symlink) mit den zusätzlichen services aus /usr/lib/systemd/system/ die man aktivieren möchte.

Targets Tabelle

SysV Runlevel Systemd Target Notes
0 runlevel0.target, poweroff.target Halt the system.
1, s, single runlevel1.target, rescue.target Single user mode.
2, 4 runlevel2.target, runlevel4.target, multi-user.target User-defined/Site-specific runlevels. By default, identical to 3.
3 runlevel3.target, multi-user.target Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5 runlevel5.target, graphical.target Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.
6 runlevel6.target, reboot.target Reboot
emergency emergency.target Emergency shell

Aktuellen Runlevel ändern

In systemd werden Runlevel über "target units" dargestellt. Ändern kann man sie mit 

# systemctl isolate graphical.target

Hiermit ändert man lediglich den aktuellen Runlevel, ohne Effekt nach einem Reboot.

Den standardmässigen Runlevel/Target in den gebootet wird ändern

Das Standardtarget ist default.target, welches standardmäßig das Alias graphical.target trägt. Im groben entspricht das Standardtarget dem alten runlevel 5. Um das targetwelches beim Booten genutzt wird zu ändern muss man folgende Kernelparameter zum bootloader hinzufügen. 

*systemd.unit=multi-user.target (entspricht in Etwa dem alten Runlevel 3).
*systemd.unit=rescue.target (was im Groben dem alten Runlevel 1 entspricht).

Alternativ kann man auch anstelle des Bootloaders default.target ändern. Hierzu kann systemctl verwendet werden: 

# systemctl enable multi-user.target

.Der Effekt dieses Kommandos wird von systemctl ausgegeben; in /etc/systemd/system/default.target wird ein neuer Symlink erstellt, der auf das neue Default-Target zeigt. Dies funktioniert jedoch nur, wenn sich 

[Install]
Alias=default.target

in der aktuellen Konfigurationsdatei des targets befindet. Derzeit befindet es sich sowohl in multi-user.target als auch in graphical.target.

Desktopumgebungen (DE) unter systemd betreiben

Displaymanager nutzen

Um grafischen Login zu aktivieren startet man seinen bevorzugten [ https://wiki.archlinux.org/index.php/Display_Manager Display Manager]daemon. Momentan existieren sevice files für GDM, KDM, XDM, LXDM und SLIM. 

# systemctl enable kdm.service

Sollte das nicht auf Anhieb funktionieren, hat man vermutlich zuvor das default.target manuell gesetzt, oder es existiert noch eines aus einer älteren Installation: 

# ls-l /etc/systemd/system/default.target
/etc/systemd/system/default-target -> /usr/lib/systemd/system/graphical.target

Man löscht nun den symlink 

#rm /etc/systemd/system/default.target

dann nutzt systemd wieder sein ursprüngliches default.target (z.B graphical.target). Wird /etc/locale.conf benutzt um locale zu setzen, muss man in /etc/environment folgenden Eintrag hinzufügen: 

LANG=en_US.utf8

(selbstverständlich ist en_US.utf8 nur als Beispiel zu betrachten).

Service Files nutzen

Hinweis: Verwendet man diese Methode, existiert keine PAM session. Aus diesem Grund funktioniert ConsoleKit nicht richtig. Die empfohlene Methode wird hier beschrieben.

Möchte man lediglich auf einfache Art und Weise X direkt und ohne Display Manager starten, kann man einen Service, ähnlich dem folgenden erstellen: 

/etc/systemd/system/graphical.target.wants/xinit.service

[Unit]
Description=Direct login to X
After=systemd-user-sessions.service

[Service]
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"

[Install]
WantedBy=graphical.target

Integration in Arch

Das Einbinden in Archs klassische Konfiguration lässt sich über das initscripts-systemd Paket bewerkstelligen. Dieses optionale Paket beinhaltet unit files und scripts die benötigt werden um die archspezifischen initscripts nachzubilden und einen Wechsel von syVinit zu systemd vereinfachen. /etc/inittab wird garnicht benutzt. /etc/rc.local und /etc/rc.local.shutdown können beim Hoch- und Herunterfahren ausgeführt werden, indem man rc.local.service und <rc.local-shutdown.service aktiviert. Vorlage:Warnung Die wenigsten User werden alle (wenn überhaupt welche) dieser units benötigen. Sie können auf einfach Art mit 

# systemctl disable <unitfile>

deaktiviert werden. Von Entwicklerseite ist geplant einen Grossteil der Funktionen dieses Paketes zu entfernen, sobald diese an anderer Stelle bedient werden (hauptsächlich in udev/systemd/kernel).

rc.conf

Einige Variablen in /etc/rc.conf werden von diesem Flickwerk beachtet. Für ein reines systemd setup wird empfohlen Native Konfigurationsdatein (LINK!) zu verwenden, da diese Vorrang vor /etc/rc.conf haben. Unterstützte Variablen sind: 

*LOCALE
*KEYMAP
*CONSOLEFONT
*CONSOLEMAP
*HOSTNAME
*MODULES
*DAEMONS: Anfordern und blacklisting wird beachtet. Wenn ein nativer systemd service file mit gleichem Namen als Daemon existiert so hat dieser Vorrang. Diese Logik kann durch systemctl disable arch-daemons.targetdeaktiviert werden.

Nicht unterstützte Variablen und saystemd Konfiguration: 

*TIMEZONE: Manuell einen Symlink von /etc/localtime zur eigenen zoneinfodatei erstellen
* HARDWARECLOCK: Localtime wird nicht unterstützt. # hwclock --systohc --utc verwenden um die Hardwareclock auf UTC zu stellen.
* USELVM: Stattdessen lvm.service aus systemd-arch-units verwenden.
* USECOLOR

rc-local.service / rc-local-shutdown.service

Führt /etc/rc.local (bzW. /etc/rc.local.shutdown) beim Booten (bzW.herunterfahren) aus.

arch-daemons.target

Analysiert die DAEMONS Zeile in /etc/rc.local und startet die services. Existiert für einen Daemon eine native systemd unit (mit gleichem Namen), wird diese benutzt. Das Script in etc/rc.d wird benutzt um die unit zu kontrollieren. Alternative: Native unit files aus dem systemd-arch-units Paket verwenden.

arch-modules-load.service

Erstellt basierend auf /etc/rc.conf eine Liste von Modulen die geladen werden sollen. (Siehe /etc/modules-load.d/rc.conf) Alternative: Erstellen einer *.conf für Module in /etc/modules-load.d/. (LINK NACH Kernelmodule für laden während des Bootens konfigurieren ===)

Mithelfen

Zwar sind momentan systemd und Archs initscripts nahezu gleichwertig, was die Eigenschaften betrifft, aber es sind trozdem noch eine Menge Tests nötig. Sollte man gern mithelfen wollen, kann man service files erstellen und sie an upstream weitergeben, oder falls das nicht klappt direkt an an den Arch Linux Bugtracker

FAQ / Häufig gestellte Fragen

Eine stets aktuelle Liste bekannter Probleme ist im upstream TODO zu finden.


Warum sehen meine Konsolenfonts so hässlich aus?

Ist in /etc/vconsole.conf (oder alternativ /etc/rc.conf) keine Schriftart definiert, wird eine Standardschrifart verwendet. Die Standardschriftart wird verwendet, weil sie zu den unterschiedlichsten landesspezifischen Schriftzeicheneigenarten kompatibel ist. Eine eigene Schriftart zu definieren löst das Problem.

Warum werden log Nachrichten auf meiner Konsole ausgegeben?

Den Kernel Loglevel muss man selbst einstellen. Ursprünglich hat /etc/rc.sysinit diese Aufgabe übernommen und den dmesg Loglevel auf 3 gesetzt, was einer angemessen ruhigen Ausgabe entspricht. Entweder loglevel=3oder loglevel=quiet in die Kernelzeile eingetragen lösen das Problem.

Warum unterstützt systemd nicht die RealTimeClock aus localtime?

Im Prinziop hindert einen nichts daran unit files hinzuzufügen, die der RTC erlauben in localtime zu sein, aber es gibt ein paar Gründe aus denen dies nicht standardmässig implementiert wurde und es wohl auch nicht wird:

  • Der Grund RTC zu erlauben in localtime zu sein war, Dualboot mit Windows wer nutzt localtime Datei:Sprache eng.png zu ermöglichen. Allerdings ist Windows seit einiger Zeit im Stande damit umzugehen wenn die RTC in UTC ist wenn man folgenden registry key setzt
HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal

Dies muss ein DWORD key mit dem Wert 1 sein. Vorlage:Warnung.

  • Mit DST umzugehen ist unübersichtlich. Sollte sich die DST ändern während der REchner ausgeschaltet ist, so geht die Uhr nach dem nächsten Boot falsch (und noch einiges mehr)
  • Aktuelle Kernel setzen die Systemzeit von der RTC direkt beim Booten, ohne hwclock zu benutzen würde der Kernel stets annehmen, dass RTC in UTC ist. Das beduetet dass wenn RTC in localtime ist, das system zuerst falsch gesetzt und unmittelbar danach nach jedem Boot korrigiert werden würde. Dies ist möglicherweise die Ursache für einige kuriose bugs (rückwärtslaufende Zeit ist in den seltensten Fällen etwas vorteilhaftes...).

Wie erstelle ich ein eigenes unit file?

Die in /etc/systemd/system/ liegenden unit files haben Vorrang vor denen in /usr/lib/systemd/system/. Um eine eigene Version einer unit zu erstellen (die auch bei einem Uprgrad nicht überschrieben wird), kopiert man das alte unit file von /usr/lib/ nach /etc/ und nimmt die Änderungen dort vor. Alternativ kann man auch .include verwenden um einen existierenden Service File zu parsen und dann die neuen Optionen hinzufügen. Möchte man beispielsweise eine zusaätzliche Abhängigkeit zu einem Service File hinzufügen, kann man folgendes verwenden: 

/etc/systemd/system/<service-name>.service

.include /usr/lib/systemd/system/<service-name>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

Wie ändere ich die Anzahl von standardmässig laufenden Gettys?

Um ein weiteres Getty hinzuzufügen erstellt man einfach einen weiteren Symlink nach /etc/systemd/system/getty.target.wants/ 

# ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
# systemctl daemon-reload
# systemctl start getty@tty9.service

Um einen Getty zu entfernen, löscht man einfach den Symlink des betreffenden Getty aus dem /etc/systemd/system/getty.targets.wants Verzeichnis: 

# rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
# systemctl daemon-reload
# systemctl stop getty@tty5.service getty@tty6.service

systemd macht keinen Gebrauch von der /etc/inittab Datei.

Hinweis: Seit systemd 30 wird standardmässig nur ein Getty gestartet. Wechselt man zu einem anderen tty, so wird dort ein getty gestartet (socket-activation Stil). Man kann trotzdem zusätzliche agetty Prozesse mittels der obengenannten Methoden erzwingen.

Wie bekomme ich inhaltsreichere Ausgaben während des Bootens?

Sieht man nach der initram Nachricht keinerlei Ausgabe auf der Konsole, ist höchstwahrscheinlich das quiet Parameter in der Kernelzeile gesetzt. Am besten entfernt man dieses, zumindest für das erste Booten mit systemd, damit man sieht ob alles wie gewünscht funktioniert. Man sieht dann eine Liste mit [OK] in grüner Schrift und [FAILED] in roter Schrift. Jede Nachricht wird im System Log notiert und wenn man den Status seines Systemes informiert werden möchte kann man entweder $ systemctl ausführen, oder sich das Boot/System Log mit journalctl ansehen.

=Wie vermeide ich, dass die Konsolenanzeige nach dem Boot gelöscht wird?

Man erstellt ein eigenes getty@tty1.service file: 

cp /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty1.service

und editiert anschliessend die Datei indem man --noclear an die ExecStartZeile nach agetty anfügt und TTYVTDeallocate auf no stellt.

Welche Kerneloptionen muss ich in meinem Kernel aktivieren, wenn ich nicht den ofiziellen Archkernel benutze?

Kernel vor 2.6.39 werden nicht unterstützt! Im Folgenden eine grobe Übersicht über die erforderlichen und empfohlenen Optionen: 

CONFIG_AUDIT=y (recommended)
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (not required, may break sysvinit compat)
CONFIG_CGROUPS=y
CONFIG_IPV6=[y|m] (highly recommended)
CONFIG_UEVENT_HELPER_PATH="" (if you don't use an initramfs)
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y (recommended, if you don't use an initramfs)
CONFIG_RTC_DRV_CMOS=y (highly recommended)
CONFIG_FANOTIFY=y (required for readahead)
CONFIG_AUTOFS4_FS=[y|m]
CONFIG_TMPFS_POSIX_ACL=y (recommended, if you want to use pam_systemd.so)

Von welchen anderen Units ist eine Unit abhängig?

Um z.B. herauszufinden welche Services ein target wie multi-user.target heranzieht, verwendet man etwas wie: 

$ systemctl show -p "Wants" multi-user.target

Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service netfs.service

Anstelle von Wants kann man z.B. auch WantedBy,Requires,RequiredBy,Conflicts,ConflictedBy,<Before>,After für entsprechende Abhängigkeiten und deren Gegenstücke einsetzen.

Optimierung

systemd-analyze

Systemd stellt mit systemd-analyze ein Werkzeug zur Verfügung, mithilfe dessen man den Bootprozess analysieren kann. So lässt sich sehen, welche unit files den Bootprozess verlangsamen. Anschliessend kann man dann sein System entsprechend optimieren. Um systemd-analyze nutzen zu können, muss dbus-python installiert sein. Um zu sehen wieviel Zeit im kernel-/userspace beim Booten verbraucht wurde setzt man: 

systemd-analyze

ab.

Hinweis: Fügt man den timestamp hook in die HOOKS Zeile der /etc/mkinitcpio.conf ein und baut anschliessend initramfs neu, kann systemd-analyze auch anzeigen, wieviel zeit im initramfs verbraucht wurde.

Mit 

systemed-analyze blame

kann man die gestarteten unit files nach der Zeit die sie brauchten um gestartet zu werden sortiert anzeigen lassen. Es ist auch möglich eine SVG Datei die den Bootprozess grafisch, ähnlich Bootchart, darstellt anzulegen. 

systemd-analyze plot > plot.svg

Bootchart gemeinsam mit systemd benutzen

Um die Bootsequenz zu visualisieren kann man eine Version von Bootchart verwenden. Da man kein zweites init in die Kernelzeile schreiben kann, kann man keines der Standard Bootchartsetups verwenden. Das bootchart2 Paket aus dem AUR beinhaltet einen undokumentierten systemd service. Nachdem bootchart2 installiert wurde führt man 

systemd-analyze plot > plot.svg

aus. Für weitere Informationen, die diese Version von Bootchart betreffen, lese man die Bootchart Dokumentation .

ACPID durch systemd ersetzen

Systemd kann einige energiebezogene ACPI events handhaben. Diese konfiguriert man über folgende Optionen in der /etc/systemd/logind.conf: 

* HandlePowerKey : Das System ausschalten wenn der Powerknopf gedrückt wird.
  • HandleSleepKey : Das System in den Suspendmodus versezten, wenn die dafür entprechende Taste gedrückt wird.
  • HandleLidSwitch : Das System in den Suspendmodus versetzen, wenn der Laptopdeckel geschlossen wird.

Diese events können, je nachdem welche Werte man für diese Optionen setzt, ausgelöst werden, wenn z.B kein User eingeloggt ist (no-session) oder nur eine einzelne Nutzersitzung aktiv ist (any-session). In man logind.conf sind detaillierte Informationen zu finden. Die genannten Optionen sollte man nur innerhalb von Desktopumgebungen wie Gnome und XFCE nutzen, da diese ACPI Ereignisse selbst handhaben. Auf Systemen ohne grafische Oberfläche, oder die lediglich über einen einfachen Fenstermanager verfügen iwe z.B i3 oder awesome können die Optionen acpid ersetzen, der normalerweise für auf diese ACPI Ereignisse reagiert.

Shell Shortcuts

Systemd daemon management erfordert ein paar mehr Texteiträge um Aufgaben wie start, stoppes, enabling, checking status usw. auszuführen. Die folgenden Funktionen kann man zu seiner ~/.bashrc hinzufügen um sich den Umgang mit systemd etwas komfortabler zu gestalten. if ! systemd-notify --booted; then # not using systemd 

 start() {
   sudo rc.d start $1
 }

 restart() {
   sudo rc.d restart $1
 }

 stop() {
   sudo rc.d stop $1
 }

else 

 start() {
   sudo systemctl start $1.service
 }

 restart() {
   sudo systemctl restart $1.service
 }

 stop() {
   sudo systemctl stop $1.service
 }

 enable() {
   sudo systemctl enable $1.service
 }

 status() {
   sudo systemctl status $1.service
 }

 disable() {
   sudo systemctl disable $1.service
 }

fi

Ausgabe beschränken

Um die Ausgabe zu beschränken tauscht man in der Kernelzeile in GRUB vebose gegen quiert Auf vielen Systemen, besonders solchen mit einer SSD stellt die langsame Performance des TTY einen Flaschenhals dar, entsprechend beschleunig weniger Ausgabe den Bootvorgang.

Abgerufen von „https://wiki.archlinux.de/index.php?title=Benutzer:Dings&oldid=13690“