Hui, da macht der Admin grosse Augen:
Startup finished in 2.051s (kernel) + 4min 7.038s (userspace) = 4min 9.089s
Mein «produktiv» genutzter, privater Debian (8) Jessie-Server braucht also unglaubliche 4 Minuten und 10 Sekunden um neu zu starten? Dabei sollte Debian Jessie dank Systemd blitzschnell hochfahren.
Heute morgen hatte ich ein bisschen Zeit mich um mein Baby zu kümmern, weswegen ich auch den neusten Kernel Minor-Patch (3.16.7-ckt20-1+deb8u1) von Debian 8 eingespielt habe. Das braucht einen Reboot. Bereits nach zwei Minuten Wartezeit auf die SSH Prompt schlägt mein Herz vor Aufregung schneller, ich fange leicht an zu zittern und mache mir ernsthafte Sorgen ob der Boot überhaupt noch klappt 🙂
Die Ursache finden: systemd-analyze
Das tolle an Systemd sind die mitgelieferten Analyzetools. Für eine Übersicht aller Dienste und deren Bootzeit reicht folgender Befehl aus:
systemd-analyze blame
Screenshot 1: fsck, grrr!
Deutlich zu erkennen ist fsck als Ursache des viel zu langsamen Systemstart (Screenshot 1).
Ich habe drei RAID 1 Partitionen auf 2×2 TB verteilt, die Grösste davon ist 1.5 Terrabyte gross. Alle drei RAID 1 /MDx Partitionen werden zwar parallel durchgescannt weil in /etc/fstab die letzte Zeile 6 eine Zahl „2“ innehat. Ja, ich habe noch EXT3 und nicht EXT4 im Einsatz.
Obwohl die drei Partitionen gleichzeitig gescannt werden dauert letztendlich der Systemstart immer noch mehr als vier Minuten.
Der Boot-Prozess als .SVG
Eine geniale Übersicht der Dienste und deren Startzeiten kann als .SVG exportiert werden:
systemd-analyze plot > my-systemd-boot-stats.svg
Das .SVG File schaut man sich am Besten in einem Browser an.
Warum rennt fsck los beim Booten?
Viel interessanter finde ich die Frage, wieso fsck die Festplatten überhaupt durchscannt. Mein System hat nämlich keinen Grund das zu tun. Gemäss Ausgabe von dumpe2fs -h /dev/md7 gibt es keine Definition von «Next [fsck] Check After:», zudem steht «Maximum mount count:» auf -1.
Dazu kommt, dass seit Systemd die Fastboot Option -f «Skip fsck on reboot» mittels shutdown -rf now nicht mehr existiert. Die Option -f ist einfach weg, sie wurde augenscheinlich ersatzlos gestrichen. Ob es noch möglich mit einer händisch erstellten Datei /fastboot den File System Check beim nächsten Boot zu übergehen, weiss ich noch nicht.
Was also löst einen fsck aus, obwohl es keine Anzeichen gibt ein fsck rennt beim nächsten boot?
In der Diskussion Please stop systemd-fsck on _every_ boot! habe ich eine mögliche Erklärung gefunden. Die CMOS Batterie könnte hinüber sein und aufgrund falschem Datum beim Hochfahren einen fsck erzwingen. Eine sehr interessante Erklärung, immerhin hatte ich auch das Gefühl die Uhr hat sich nach dem Restart verstellt bevor ntp diese synchronisiert.
Aber noch kann ich das nicht prüfen, niemand möchte seinen «produktiven» Server im Minutentakt restarten. Vielleicht ergibt sich ja über die Weihnachtstage ein günstiger Zeitpunkt.
2 Kommentare
Axel Birndt · 7. Dezember 2016 um 12:43
Hallo David,
konntest du mittlerweile herausfinden, ob rs die CMOS-Batterie war?
Cu, Axel
Schroeffu · 7. Dezember 2016 um 23:27
Hey Axel,
muss gestehen, leider nein. Ich hab den Server seither öfters mal rebooted nach einem Kernel Patch, getriggert jeweils auf 04 Uhr.
Die Überwachung hat nicht angeschlagen was eigentlich bedeutet, der Ausfall war unter 5 Minuten.
Ich lasse meine Dienste von uptimerobot.com monitoren, super Service für kostenlos mit Twitter-Push wenns down geht.
Ich bin ja dabei einen Umzug zu planen, nur, ich hab echt kaum Zeit dafür… Als Erstes möchte ich den Mailserver umziehen und gleichzeitig frisch bauen, ich dachte daran Mailcow einzisetzen.
Alles von Hand selbst wieder einrichten ist einfach qualvoll, zumal ich bis heute keine GUi hab wo Mail-User selbst Weiterleitungen oder Spamfiler einrichten können. Mailcow richtet das alles direkt ein.
Wenn der Mailserver mal gemoved ist (7 Domains, ca 25 Boxen) ist der Rest nur noch ein Klacks. Zumindest im Vergleich zu nem verkomplizierten Maildienst ^.^