Abbildung 5: Die Ausgabe des Befehls systemd-analyze critical-chain rc-local.service.
An dieser Stelle zeigt sich, dass das nur bedingt eine gute Wahl ist. Zum einen lässt sich die Abarbeitung der rc.local nicht beeinflussen – Abbildung 5 zeigt, dass das erst nach der vollständigen Netzwerkkonfiguration geschieht. Zum anderen bezieht man so nur Informationen über den Start der rc.local, nicht aber über den Start des eigenen Anwendungsprogramms. In unserem Fall ist das zwar quasi identisch, aber das ist nicht generell so.
Eigenen Service etablieren
Der erste Schritt zum Optimieren der Boot-Zeiten führt also über die Definition eines eigenen Services. Das gelingt mit wenigen Zeilen in einer Textdatei, die Sie in /etc/systemd/system/bootende.service anlegen (Listing 2). Den Service aktivieren Sie mit folgendem Kommando:
$ sudo systemctl enable bootende.service
Listing 2
[Unit] Description=Messprogramm Bootende After=local-fs.target DefaultDependencies=no Conflicts=shutdown.target [Service] Type=simple ExecStart=/usr/local/bin/bootende.sh [Install] WantedBy=local-fs.target
Interessant sind hier vor allem die Angabe WantedBy im Abschnitt [Install] sowie die Angabe After unter [Unit]. Diese Informationen legen die Abhängigkeiten zu anderen Services fest. Wer etwa ein Datenbanksystem startet, benötigt das Netzwerk und wählt statt des local-fs.target das multi-user.target.
Für die in der Einleitung genannten Beispiele Küchenwecker und Wildkamera spielt das Netzwerk aber keine Rolle: Diese Programme sollen starten, sobald die Dateisysteme bereitstehen. Den Lohn der Mühen zeigt Abbildung 6: Nach einem Neustart und erneutem Aufruf von systemd-analyze critical-chain halbiert sich die Startzeit der Anwendung nahezu, zumindest was die Systeminitialisierung betrifft.
Abbildung 6: Entsprechend optimierte Abhängigkeiten verkürzen die Boot-Zeit deutlich.
Die Tabelle “Gemessene Boot-Zeiten in Sekunden” gibt eine Übersicht über die diversen Zeiten, getrennt nach Gesamtzeit (Messung vom Anschalten des Stroms bis zur Rückmeldung an den Mess-Pi), der Kernel-Zeit und der Anwendungszeit. Die Kernel-Zeit stammt jeweils aus der Ausgabe von systemd-analyze time, die Zeit für den Anwendungsstart aus systemd-analyze cricital-chain bootende.service.
Der Messfehler beträgt prinzipbedingt 0,1 Sekunden, darüber hinaus schwankt die gemessene Zeit auch um denselben Wert. Wenn eine Maßnahme also eine Änderung der Boot-Zeit von 0,2 Sekunden einbringt, könnte auch der Zufall dafür verantwortlich zeichnen.
|
Nummer |
Gesamt |
Kernel |
Anwendung |
Beschreibung/Anpassung |
|---|---|---|---|---|
|
1 |
35,9 |
2,0 |
30,0 |
Raspbian Standard, Start aus |
|
2 |
23,5 |
2,0 |
16,3 |
Raspbian Standard, eigener Service ( |
|
3 |
14,5 |
2,0 |
7,3 |
zusätzlich ohne |
|
4 |
14,3 |
2,0 |
7,1 |
|
|
5 |
14,0 |
1,7 |
7,1 |
|
|
6 |
12,4 |
1,7 |
5,2 |
|
|
7 |
12,1 |
1,6 |
5,2 |
|
|
8 |
12,1 |
1,6 |
5,2 |
|
|
9 |
12,1 |
1,6 |
5,2 |
|
|
10 |
12,0 |
1,5 |
5,2 |
|
|
11 |
7,6 |
1,4 |
1,4 |
wie 10, aber mit RasPi 3B statt Pi Zero W |
Niedrig hängende Früchte
Eine einzelne Maßnahme führt schon beinahe zu einer Halbierung der Boot-Zeit. So niedrig hängen die Früchte jetzt nicht mehr, aber die Abbildung 6 gibt einen Hinweis darauf, wo noch etwas geht.
Dazu markiert die Ausgabe die lang laufenden Tasks in Rot. Zeiten nach dem Klammeraffen (@) stehen für Zeitpunkte relativ zum Start von Systemd, die Zeiten nach dem Plus-Zeichen dagegen für Laufzeiten der Tasks. Hier sticht der Task am Anfang der Kette (ganz unten) ins Auge.
Die etwas kryptische Zeile weist auf den Filesystem-Check und auf das Einhängen der ersten Partition (/boot) hin. Die Dateien auf dieser Partition, wie der Kernel und die Firmware, sind für den Systemstart essenziell, danach aber irrelevant. Wer am System schraubt oder ein Update einspielt, muss aber das Dateisystem einhängen.
In allen anderen Fällen ist das nicht nötig, schadet aber nicht – außer dass es Zeit kostet. Um die Boot-Zeit also noch etwas zu drücken, kommentieren Sie die Zeile in der /etc/fstab einfach aus, was weitere neun Sekunden spart. Da wir im nächsten Abschnitt noch ein paar Änderungen an der /boot/config.txt vornehmen, verschieben wir das aber auf einen späteren Zeitpunkt.
Nach jeder Optimierung sollten Sie die Ausgabe des Systemd-analyze-Kommandos noch einmal unter die Lupe nehmen: Fällt ein Hemmschuh weg, kommt ein anderer zum Tragen. Im Beispiel ist das der Service keyboard-setup.service, der fast zwei Sekunden benötigt und bei eingebetteten Anwendungen ohne Tastatur entfallen kann. Folgender Befehl schaltet den Service ab:
$ sudo systemctl disable keyboard-setup.service
Einen weiteren Optimierungspunkt bietet das Überprüfen der Dateisysteme. Raspbian ist hier sehr konservativ und erzwingt durch den Schalter fsck.repair=yes in der /boot/cmdline.txt eine Überprüfung bei jedem Systemstart. Da der Kernel selbst merkt, ob er die Dateisysteme prüfen muss, braucht man das eigentlich nicht.
