Benutzer:Dings: Unterschied zwischen den Versionen

Aus wiki.archlinux.de
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „There is no i in team.“)
 
Zeile 1: Zeile 1:
There is no i in team.
+
{{righttoc}}
 +
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 <code>init=/bin/systemed</code> in die Kernelzeile des Bootloaders.
 +
 
 +
Systemd kann parallel zu den regulären Archlinux Initscripts installiert werden und mittels hinzufügen/entfernen des <code>init=/bin/systemd</code> Kernelparameters aktiviert bzW. deaktiviert werden.
 +
Möchte man ein reines systemd setup verwenden, entfernt man initscripts und installiert [https://www.archlinux.org/packages/?name=systemd-sysvcompat systemd-sysvcompat].Sytemd-sysvcompat liefert symlinks für <code>init</code>, <code>reboot</code> usw. . Beim Verwenden des reinen systmd setups braucht das <code<init=</code> parameteter in der Kernelzeile nicht gesetzt zu werden.
 +
{{warnung|<code>udev</code> und etliche andere Software erwarten dass das <code>/usr<code> Verzeichnis beim Booten gemountet und verfügbar ist. Sollte sich das <code>/usr</code> Verzeichnis auf einer separaten Partition befinden, müssen Vorkehrungen getroffen werden das Verzeichnis aus initramfs zu mounten und von einem angepassten root beim Herunterfahren zu unmounten. Näheres hierzu findet man auf der [https://wiki.archlinux.org/index.php/Mkinitcpio#.2Fusr_as_a_separate_partition mkinitcpio Wiki Seite] {{sprache|en}} und [http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken hier] {{sprache|en}}.}}
 +
 +
== Konfigurationsdateien ==
 +
=== Hostnamen hinzufügen ===
 +
Der Hostname wird in <code>/etc/hostname</code> 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 <code>/etc/vconsole.conf</code> 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 <code>man locale.conf</code>
 +
/etc/locale.conf
 +
Lang=en_US.UTF-8
 +
LC_COLLATE=C
 +
 +
=== Festlegen der Zeitzone ===
 +
/etc/timezone
 +
Europe/Lummerland
 +
 
 +
{{hinweis|Auch wenn man <code>/etc/timzone</code> verwendet wird trotzdem <code>/etc/localtime</code> benötigt!}}
 +
 
 +
=== Kernelmodule für laden während des Bootens konfigurieren ===
 +
Während des bootens verwendet systemed in <code>/etc/modules-load.d/</code> abgelegte Konfigurationsdateien. Jede Konfigurationsdatei muss nach dem Schema <code>/etc/modules-load.d/<program>.conf</code> 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 <code>#</code> oder <code>;</code> ist, werden ignoriert.
 +
Beispiel:
 +
/etc/modules-load.d/virtio-net.conf
 +
 +
# Laedt virtio-net.ko beim Booten
 +
virtio-net
 +
Siehe [https://wiki.archlinux.org/index.php/Modprobe#Options Modprobe#Options]{{sprache|en}}.
 +
 
 +
=== Kernelmodule ausschließen / blacklist ===
 +
Das Erstellen einer schwarzen Liste für Kernelmodule kann in gleicher Weise Weise wie bei [https://www.archlinux.org/packages/?name=initscripts initscripts] vorgenommen, da eigentich [https://www.archlinux.org/packages/?name=kmod kmod] die Listen verarbeitet. Für Details siehe auch [https://wiki.archlinux.org/index.php/Kernel_modules#Blacklisting Module Blacklisting]{{sprache|en}}.
 +
BEISPIEL EINFÜGEN
 +
 
 +
=== Temporäre Dateien ===
 +
Systemed-tmpfiles verwendet in <code>/etc/tmpfiles.d/</code> abgelegte Konfigurationsdateien um erstellen, säubern und entfernen temporärer Dateien, die sich normalerweise in normalerweise in Verzeichnissen wie <code>/run</code> oder <code>/tmp</code> befinden. Jede Konfigurationsdatei in <code>/etc/tmpfiles.d</code> wird nach dem Schema <code>/etc/tmpfiles.d/<program>.conf</code> benannt. Konfigurationsdateien in <code>/etc/tmpfiles.d/</code> heben die Wirkung gleichnamiger Dateien in <code>/usr/lib/tmpfiles.d/</code> auf! Tmpfiles werden normalerweise zusammen mit Servicedateien bereitgestellt, um Verzeichnisse zu erstellen deren Existenz von verschiedenen Daemonen erwartet wird. Beispielsweise erwartet der [https://wiki.archlinux.de/title/Samba Samba]daemon, dass das Verzeichnis <code>/var/run/samba</code> 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 <code>/etc/rc.local</code> um via <code>echo USBE > /proc/acpi/wakeup</code> 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 <code>/etc/rc.local</code> nicht untertützt.
 +
Unter <code>man tmpfiles.d</code> 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 <code>run/systemd/journal</code>, was bedeutet das nach einem reboot die logs gelöscht sind. Um die logs dauerhaft zu bewahren, legt man das Verzeichnis <code>/var/log/journal/</code> an:
 +
# mkdir /var/log/journal
 +
==== Journald im Zusammenhang mit einem klassischen syslogdaemon ====
 +
Die Kompatiblität mit klassischen syslog Implementierungen wird über einen socket <code>/run/systemd/journal/syslog</code>, an den alle Nachrichten weitergeleitet werden, gewährleistet. Damit der syslogdaemon mit dem journal arbeitet, muss es anstatt an <code>/dev/log/</code> an <code>/run/systemd/journal/syslog</code> gebunden werden.([http://lwn.net/Articles/474968/ Offizielle Bekanntmachung hierzu]{{sprache|en}}). Für die Nutzung von <code>syslog-ng</code> ändert man den source Abschnitt in <code>/etc/syslog-ng/syslog-ng.conf</code> folgendermassen ab
 +
source src {
 +
    unix-dgram("/run/systemd/journal/syslog");
 +
    internal();
 +
    file("/proc/kmsg");
 +
};
 +
und aktiviert (oder reaktiviert) <code>syslog-ng</code>:
 +
# systemctl enable syslog-ng.service
 +
. Standardmäßig ist journald so konfiguriert, dass es aus <code>/proc/kmsg</code> liest, dies kollidiert allerdings mit einer syslog Implementierung, die das selbe tut [http://lists.freedesktop.org/archives/systemd-devel/2012-January/004310.html systemd-devel post]{{sprache|en}}. Man deaktiviert das <code>systemd-journald</code> aus <code>/proc/kmsg</code> liest, indem man
 +
ImportKernel=0
 +
in die <code>/etc/systemd/journald.conf</code> einträgt.
 +
===Netzwerk===
 +
====Dynamisch (DHCP)====
 +
Nutzt man für seine Ethernetverbindung lediglich DHCP, kann man <code>dhcpcd@.service</code> aus dem [https://www.archlinux.org/packages/?name=systemd-arch-units systemd-arch-units] Paket verwenden. Man aktiviert DHCP für <code>eth0</code> 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 <code>eth0</code> 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 [https://wiki.archlinux.org/index.php/Netcfg netcfg]{{sprache|en}} oder [https://wiki.archlinux.org/index.php/NetworkManager NetworkManager]{{sprache|en}} benutzen. Beide stellen systemd service files bereit. Benötigt man zwar eine statische Netzwerkkonfiguration, möchte aber nicht [https://wiki.archlinux.org/index.php/Netcfg netcfg]{{sprache|en}} benutzen, so findet man auf der [https://wiki.archlinux.org/index.php/Systemd/Services#Network Systemd/Services Seite]{{sprache|en}} eine angepasste Service Datei.
 +
===Remote filesystem mounts===
 +
Hat man NFS mounts in die <code>/etc/fstab</code> 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 <code>rpc.statd</code> den Mountvorgang anstossen. Dies erreicht man indem man die Datei <code>/etc/systemd/system/<mount-unit-name>.mount</code> 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
 +
*<code>mount-unit-name</code> ist der volle Pfad zum Einhängepunkt (Mountpoint) im „escaped“-Format. Z.B.: mount unit für <code>/usr/local</code> muss als <code>usr-local.mount</code> benannt werden.
 +
  *<code>mountpoint</code> ist der lokale Einhängepunkt (Mountpoint)
 +
*<code>server:share</code> definiert das remote filesystem in der gleichen Art wie man es in der <code>/etc/fstab<code> tut.
 +
<code>systemd.unit(5)</code> und <code>systemd.mount(5)</code> 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 <code>etc/fstab</code> mit den <code>x-systemd.automount</code> und <code>x-systemd.device-timeout=#</code> Optionen vornehmen (siehe <code>systemd.mount(5)</code>. Es ist hierbei sicherzustellen, dass falls auch <code>defaults</code> als Mountoption verwendet wird, das eingeschlossene <code>auto</code> mit <code>noauto</code> ersetzt wird. Hierdurch wird das Gerät beim ersten Zugriff eingehängt, ähnlich wie [https://wiki.archlinux.org/index.php/Autofs Autofs]{{sprache|en}}.
 +
===Systemd verwenden===
 +
*<code>sytemctl</code>: wird verwendet um den Zustand des systemd System und Service Managers zu prüfen und zu kontrollieren.
 +
*<code>systemd-cgls</code>: zeigt rekursiv die Inhalte der gewählten Linux Control Group Hirarchie als Baumschema.
 +
*<code>systemadm</code> 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 [https://aur.archlinux.org/packages.php?K=systemd-ui-git&SeB=x systemd-ui-git] Paket aus dem [https://wiki.archlinux.de/title/ArchLinux_User-Community_Repository 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 <code>/usr/lib/systemd/system/</code> und <code>/etc/systemd/system/</code>(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 <code>man systemctl</code> 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 <code>telinit RUNLEVEL</code>-Befehls zwischen ''targets'' umschalten kann.
 +
==Den aktuellen Runlevel / aktuelles Target ermitteln==
 +
Unter systemd sollte
 +
# systemctl list-units --type=target
 +
anstelle von <code>runlevel</code> 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 <code>/etc/systemd/system/<mein target> auf der Basis eines existierenden Runlevels (als Beispiel kann man <code>/usr/lib/systemd/graphical.target</code> heranziehen) zu erstellen. Anschliessend erstellt man ein Verzeichnis <code>/etc/systemd/system/<mein target>.wants</code> und verlinkt (symlink) mit den zusätzlichen services aus <code>/usr/lib/systemd/system/</code> die man aktivieren möchte.
 +
=== Targets Tabelle ===
 +
{| border="1"
 +
!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 <code>default.target</code>, welches standardmäßig das Alias <code>graphical.target</code> trägt. Im groben entspricht das Standardtarget dem alten runlevel 5. Um das ''target''welches beim Booten genutzt wird zu ändern muss man folgende Kernelparameter zum bootloader hinzufügen.
 +
*<code>systemd.unit=multi-user.target</code> (entspricht in Etwa dem alten Runlevel 3).
 +
*<code>systemd.unit=rescue.target</code> (was im Groben dem alten Runlevel 1 entspricht).
 +
Alternativ kann man auch anstelle des Bootloaders <code>default.target</code> ändern. Hierzu kann <code>systemctl</code> verwendet werden:
 +
# systemctl enable multi-user.target
 +
.Der Effekt dieses Kommandos wird von <code>systemctl</code> ausgegeben; in <code>/etc/systemd/system/default.target</code> 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 <code>multi-user.target</code> als auch in <code>graphical.target</code>.
 +
==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{{sprache|en}}. Momentan existieren sevice files für [https://wiki.archlinux.de/title/Login-Manager#GDM GDM], [https://wiki.archlinux.de/title/Login-Manager#KDM KDM], [https://wiki.archlinux.de/title/Login-Manager#XDM XDM], [https://wiki.archlinux.de/title/Login-Manager#LXDM LXDM] und [https://wiki.archlinux.de/title/Login-Manager#SLiM SLIM].
 +
# systemctl enable kdm.service
 +
Sollte das nicht auf Anhieb funktionieren, hat man vermutlich zuvor das <code>default.target</code> 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 <code>default.target</code> (z.B <code>graphical.target</code>).
 +
Wird <code>/etc/locale.conf</code> benutzt um locale zu setzen, muss man in <code>/etc/environment</code> 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 [https://wiki.archlinux.org/index.php/Automatic_login_to_virtual_console#With_systemd hier]{{sprache|en}} 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 [https://www.archlinux.org/packages/?name=initscripts-systemd 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.
 +
<code>/etc/inittab</code> wird garnicht benutzt.
 +
<code>/etc/rc.local</code> und <code>/etc/rc.local.shutdown</code> können beim Hoch- und Herunterfahren ausgeführt werden, indem man <code>rc.local.service</code> und <rc.local-shutdown.service</code> aktiviert.
 +
{{Warnung| Es wird nicht empfohlen dieses Paket zu verwenden. Im Besonderen werden <code>arch-load-modules.service</code> und <code>arch-daemons.target</code> in Zukunft entfernt werden. Man sollte wo immer es möglich ist auf native systemd Konfigurationsdateien zurückgreifen!}}
 +
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 <code>/etc/rc.conf</code> werden von diesem Flickwerk beachtet. Für ein reines systemd setup wird empfohlen Native Konfigurationsdatein (LINK!) zu verwenden, da diese Vorrang vor <code>/etc/rc.conf</code> 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 <code>systemctl disable arch-daemons.target</code>deaktiviert werden.
 +
Nicht unterstützte Variablen und saystemd Konfiguration:
 +
*TIMEZONE: Manuell einen Symlink von <code>/etc/localtime</code> zur eigenen zoneinfodatei erstellen
 +
* HARDWARECLOCK: Localtime wird nicht unterstützt. <code># hwclock --systohc --utc</code> verwenden um die Hardwareclock auf UTC zu stellen.
 +
* USELVM: Stattdessen <code>lvm.service</code> aus [https://www.archlinux.org/packages/?name=systemd-arch-units systemd-arch-units] verwenden.
 +
* USECOLOR
 +
==== rc-local.service / rc-local-shutdown.service ====
 +
Führt <code>/etc/rc.local</code> (bzW. <code>/etc/rc.local.shutdown) beim Booten (bzW.herunterfahren) aus.
 +
==== arch-daemons.target ====
 +
Analysiert die <code>DAEMONS</code> Zeile in <code>/etc/rc.local</code> und startet die services. Existiert für einen Daemon eine native systemd unit (mit gleichem Namen), wird diese benutzt. Das Script in <code>etc/rc.d</code> wird benutzt um die unit zu kontrollieren.
 +
Alternative: Native unit files aus dem [https://www.archlinux.org/packages/?name=systemd-arch-units systemd-arch-units] Paket verwenden.
 +
==== arch-modules-load.service ====
 +
Erstellt basierend auf <code>/etc/rc.conf</code> eine Liste von Modulen die geladen werden sollen. (Siehe <code>/etc/modules-load.d/rc.conf</code>)
 +
Alternative: Erstellen einer <code>*.conf</code> 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 [https://bugs.archlinux.org/ Arch Linux Bugtracker]{{sprache|en}}
 +
 
 +
==FAQ / Häufig gestellte Fragen==
 +
Eine stets aktuelle Liste bekannter Probleme ist im [http://cgit.freedesktop.org/systemd/systemd/tree/TODO upstream TODO]{{sprache|en}} zu finden.
 +
 
 +
 
 +
 
 +
====Warum sehen meine Konsolenfonts so hässlich aus?====
 +
Ist in <code>/etc/vconsole.conf</code> (oder alternativ <code>/etc/rc.conf</code>) 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 <code>/etc/rc.sysinit</code> diese Aufgabe übernommen und den dmesg Loglevel auf 3 gesetzt, was einer angemessen ruhigen Ausgabe entspricht. Entweder <code>loglevel=3</code>oder <code>loglevel=quiet</code> in die Kernelzeile eingetragen lösen das Problem.
 +
 
 +
====Warum unterstützt systemd nicht die '''R'''eal'''T'''ime'''C'''lock 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 [http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx wer nutzt localtime] {{sprache|eng}} 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.
 +
{{Warnung|Auf neuesten Systemen (Windows 7, Vista SP2) hindert diese Einstellung Windows daran, die System Uhr überhaupt zu aktualisieren, [http://social.msdn.microsoft.com/forums/en-US/tabletandtouch/thread/0b872d8a-69e9-40a6-a71f-45de90c6e243/ und frühere Versionen arbeiten nicht korrekt, wenn sie aus dem Suspend- oder Hibernatemodus erwachen]{{sprache|en}}. Obendrein könnten neuere Systeme [http://support.microsoft.com/kb/2687252 während des DSTwechsels (Daylight Saving Time) einfrieren, wenn RealTimeIsUniversal gesetzt ist]{{sprache|en}}}}.
 +
* 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 ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html und noch einiges mehr]{{sprache|en}})
 +
* Aktuelle Kernel setzen die Systemzeit von der RTC direkt beim Booten, ohne <code>hwclock</code> 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 <code>/etc/systemd/system/</code> liegenden unit files haben Vorrang vor denen in <code>/usr/lib/systemd/system/</code>. Um eine eigene Version einer unit zu erstellen (die auch bei einem Uprgrad nicht überschrieben wird), kopiert man das alte unit file von <code>/usr/lib/</code> nach <code>/etc/</code> und nimmt die Änderungen dort vor. Alternativ kann man auch <code>.include</code> 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 <code>/etc/systemd/system/getty.target.wants/</code>
 +
# 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 <code>/etc/systemd/system/getty.targets.wants</code> 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 <code>/etc/inittab</code> 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 <code>quiet</code> 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 <code>$ systemctl</code> ausführen, oder sich das Boot/System Log mit <code>journalctl</code> 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
 +
<code>--noclear</code> an die <code>ExecStart</code>Zeile nach <code>agetty</code> anfügt und <code>TTYVTDeallocate</code> auf <code>no</code> 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 <code>multi-user.target</code> 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 <code>Wants</code> kann man z.B. auch <code>WantedBy</code>,<code>Requires</code>,<code>RequiredBy</code>,<code>Conflicts</code>,<code>ConflictedBy</code>,<Before>,<code>After</code> für entsprechende Abhängigkeiten und deren Gegenstücke einsetzen.
 +
 
 +
==Optimierung==
 +
===systemd-analyze===
 +
Systemd stellt mit <code>systemd-analyze</code> 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 <code>systemd-analyze</code> nutzen zu können, muss [https://www.archlinux.org/packages/?name=dbus-python 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 <code>timestamp<code> hook in die <code>HOOKS</code> Zeile der <code>/etc/mkinitcpio.conf</code> ein und baut anschliessend initramfs neu, kann <code>systemd-analyze</code> 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 [https://aur.archlinux.org/packages.php?K=bootchart2&SeB=x bootchart2] Paket aus dem [[AUR]] beinhaltet einen undokumentierten systemd service. Nachdem [https://aur.archlinux.org/packages.php?K=bootchart2&SeB=x 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 [https://github.com/mmeeks/bootchart Bootchart Dokumentation] {{sprache|en}}.
 +
==ACPID durch systemd ersetzen==
 +
Systemd kann einige energiebezogene ACPI events handhaben. Diese konfiguriert man über folgende Optionen in der <code>/etc/systemd/logind.conf</code>:
 +
* <code>HandlePowerKey</code> : Das System ausschalten wenn der Powerknopf gedrückt wird.
 +
*<code>HandleSleepKey</code> : Das System in den Suspendmodus versezten, wenn die dafür entprechende Taste gedrückt wird.
 +
*<code>HandleLidSwitch</code> : 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
 +
(<code>no-session</code>) oder nur eine einzelne Nutzersitzung aktiv ist
 +
(<code>any-session</code>). In <code>man logind.conf<code> 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 <code>~/.bashrc</code> hinzufügen
 +
um sich den Umgang mit systemd etwas komfortabler zu gestalten.
 +
<code>
 +
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
 +
</code>
 +
===Ausgabe beschränken===
 +
Um die Ausgabe zu beschränken tauscht  man in der Kernelzeile in GRUB <code>vebose</code> gegen <code>quiert</code> Auf vielen Systemen, besonders solchen mit einer SSD stellt die langsame Performance des TTY einen Flaschenhals dar, entsprechend beschleunig weniger Ausgabe den Bootvorgang.

Version vom 2. November 2012, 17:06 Uhr

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#OptionsSprache en.png.

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 BlacklistingSprache en.png.

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 hierzuSprache en.png). 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 postSprache en.png. 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 netcfgSprache en.png oder NetworkManagerSprache en.png benutzen. Beide stellen systemd service files bereit. Benötigt man zwar eine statische Netzwerkkonfiguration, möchte aber nicht netcfgSprache en.png benutzen, so findet man auf der Systemd/Services SeiteSprache en.png 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 AutofsSprache en.png.

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]daemonSprache en.png. 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 hierSprache en.png 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 BugtrackerSprache en.png

FAQ / Häufig gestellte Fragen

Eine stets aktuelle Liste bekannter Probleme ist im upstream TODOSprache en.png 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 mehrSprache en.png)
  • 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 Sprache en.png.

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.