Veröffentlicht am 16. Februar 2015
|
Comments
Vor ca. zwei Wochen habe ich für ngb.to einen Quake-3-Arena-Server auf Basis von ioquake aufgesetzt. Als Distribution habe ich Arch Linux gewählt. Nachdem alles installiert war, wollte ich den Q3A-Server nach dem Booten und nach einem eventuellen Absturz, neu starten lassen. Mittels eines systemd-Service kein Problem. Nur ist Q3A an sich eine Quasselstrippe und müllt die Logdateien gnadenlos zu. Vor allem, wenn gezockt wird. Hier bin ich mir nicht sicher wie lange das mit der, im Raspberry Pi verbauten, Speicherkarte gut geht. Daher musste ein Weg her, um Q3A zum Schweigen zu bringen.
Nach einer kurzen Suche in der Dokumentation von systemd wurde ich fündig. Hier hilft StandardOutput= weiter. Hierüber kann man die Standardausgabe eines Service definieren. Zur Auswahl stehen inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console sowie socket. Da mich die Standardausgabe (X has joined usw.) nun wirklich nicht interessiert, war ich gnadenlos und habe null gewählt. Somit werden die ganzen Ausgaben direkt gemülleimert und das Journal und somit auch die Speicherkarte werden geschont. Herausgekommen ist dann folgender Service.
[Unit]
Description=Startet ioquake3-Server
[Service]
User=q3a
ExecStart=/pfad/zum/Startscript/q3a.sh
StandardOutput=null
Restart=always
[Install]
WantedBy=multi-user.target
Wenn man will, kann man auch noch StandardError= für eventuell auftretende Fehler definieren. Hier gelten wieder oben genannte Möglichkeiten. Gibt man dies nicht direkt in der Service-Datei an, wird der Standard inherit verwendet.
Veröffentlicht am 8. Dezember 2014
|
Comments
Systemd bietet sogenannte Targets. Grob gesagt so etwas wie die Runlevel wie man sie von sysVinit her kennt. Multi-user.target entspricht hier am ehesten Runlevel 3. Graphical.target Runlevel 5. Um sich eine Übersicht zu verschaffen welche Services zum Beispiel das Target multi-user.target ausführen möchte, kann man folgenden Befehl verwenden:
systemctl show -p "Wants" multi-user.target
Als Ergebnis erhält man dann beispielsweise folgende Ausgabe:<
Wants=cronie.service openvpn@nvpn.service unbound.service remote-fs.target systemd-networkd.service
haveged.service updatedb.timer shadow.timer rpcbind.service logrotate.timer man-db.timer
nsystemd-logind.service systemd-user-sessions.service getty.target systemd-ask-password-wall.path
ndbus.service
Anstelle von Wants kann auch WantedBy, Requires, RequiredBy, Conflicts, ConflictedBy, Before, After genutzt werden. Eine genauere Erklärung der sogenannten Section Options findet man hier. Daher gehe ich hier nicht näher darauf ein.
Veröffentlicht am 27. August 2014
|
Comments
In den letzten Wochen war es mal wieder hip gegen systemd zu sticheln. Einige Personen hatten es zum Beispiel auf den Service systemd-tmpfiles-clean abgesehen. Mit diesem werden temporäre Dateien nach einer bestimmten Zeitspanne automatisch gelöscht. Die Standardeinstellung für /tmp ist 10 Tage, die für /var/tmp 30 Tage.
Es wurde nun argumentiert, dass diese Einstellungen für die meisten Nutzer blödsinnig wären. Wie gut, dass man etwas dagegen machen kann. Fangen wir mal damit an, die Fristen auf die persönlichen Bedürfnisse anzupassen. Die betreffende Konfigurationsdatei findet man unter /usr/lib/tmpfiles.d/ und nennt sich tmp.conf. Diese sieht bei mir wie folgt aus.
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See tmpfiles.d(5) for details
# Clear tmp directories separately, to make them easier to override
d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d
# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp
Die ersten beiden Zeilen setzen sich wie folgt zusammen. |Typ|Pfad|Rechte|UID|GID|Alter|. Für viele ist vermutlich das Alter interessant, ab dem gelöscht wird. Hier kann man sich entsprechend austoben. Mögliche Zeiteinheiten sind s, min, h, d, w, ms, m, us. Diese müssen ohne Leerzeichen angegeben werden. Also z. B. 10d oder 10d12h.
Will man z. B. ein Unterverzeichnis vom automatischen Bereinigen ausnehmen ist der Typ x, wie man es im zweiten Block sehen kann, die Wahl der Waffe.
Unter http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html (Englisch) kann man sich den ganzen Spaß noch genauer und ausführlicher durchlesen.
Was aber, wenn man gar kein automatisches Bereinigen der temporären Dateien wünscht? Am einfachsten ist es wohl den Service einfach zu deaktivieren.
Abschließend bleibt mir eigentlich nur noch eines zu sagen. Dieses Argument gegen systemd ist eigentlich gar kein Argument. Es zeigt eigentlich nur, dass sich viele systemd-Gegner nicht wirklich mit systemd-Projekt beschäftigt haben. Und nein, systemd ist trotz allem nicht der heilige Gral. Ich musste mich auch schon einige Zeit mit der Meldung “a stop job ist running for User Manager for UID 1026” und dem damit verbundenen Countdown von 90 Sekunden beim Herunterfahren meines Hauptrechners herumschlagen.
Veröffentlicht am 26. August 2014
|
Comments
Vor ein paar Minuten ist mit aufgefallen, dass die Uhr unter lxde um ein paar Minuten falsch läuft. Wie es sich herausgestellt hat, hatte ich schlicht und ergreifend vergessen NTPD zu installieren. Bei der Gelegenheit habe ich jetzt allerdings timesyncd getestet. Dies ist ein Service aus dem systemd-Projekt (nicht dem init-Dienst), welcher für meine Anforderungen das Gleiche wie NTP macht. Es gleicht die Uhr meines Rechners mit einem Zeitserver im Internet ab.
Als Erstes habe ich mir die Konfigurationsdatei /etc/systemd/timesyncd.conf vorgenommen. Diese ist im Auslieferungszustand sehr übersichtlich.
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See timesyncd.conf(5) for details
[Time]
#Servers=time1.google.com time2.google.com time3.google.com time4.google.com
Eigentlich muss man in der letzten Zeile nur das # entfernen und die Datei speichern.
Als Nächstes habe ich dann mittels “systemctl start timesyncd” den Service gestartet. Da es keinerlei Beschwerden gab, folgte ein “systemctl enable timesyncd” um den Service automatisch zu starten. Abschließend habe ich den Rechner neu gestartet. Und die Uhr lief trotzdem um ein paar Minuten falsch… Also mal Tante Google fragen. Nach wenigen Sekunden hatte ich die Antwort. Damit timesyncd funktioniert muss auch systemd-networkd laufen. Da ich aber netctl für meine Netzwerkverbindungen nutze, ist mir das aber nicht so recht. Aber vielleicht reicht es ja, wenn systemd-networkd nur läuft aber nicht konfiguriert ist… Probieren wir es aus und aktivieren wir den Dienst mittels “systemctl enable systemd-networkd” und starten die Büchse neu. Und schwupps funktioniert timesyncd, obwohl ich netctl nutze. Vermutlich werde ich aber trotzdem wieder auf ntpd umschwenken, da ich damit systemd-networkd nicht laufen lassen muss.
Veröffentlicht am 18. August 2014
|
Comments
Wenn man herausfinden will, welcher Service beim Booten mit systemd den Bootprozess verlangsamt, kann man dies mittels “systemd-analyze critical-chain” recht gut darstellen.
multi-user.target @28.246s
└─clamav-freshclam.service @27.657s +247ms
└─clamav-daemon.service @3.042s +24.604s
└─basic.target @3.026s
└─sockets.target @3.023s
└─dbus.socket @3.021s
└─sysinit.target @3.017s
└─ferm.service @2.756s +259ms
└─network.target @2.752s
└─networking.service @427ms +2.323s
└─local-fs.target @410ms
└─run-lock.mount @396ms +11ms
└─local-fs-pre.target @384ms
└─systemd-udevd.service @303ms +20ms
└─systemd-tmpfiles-setup-dev.service @208ms +80ms
└─systemd-journald.socket @114ms
└─-.mount @100ms
Die Angabe nach dem @ zeigt an, wie lange der Service aktiv ist. Die Zahl hinter dem + zeigt an, wie lange der Service zum Starten gebraucht hat. So kann man recht gut herausfinden, welcher Probleme macht.