|
|
| (3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| {{Unvollständig}}
| |
| {{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.
| |