HAPPYTEC.at :: Blog

Einer meiner Raspberry Pi's stand seit 2013 in einem Rechenzentrum in Graz. Seit meinem letzten Statusupdate sind mehr als neun Jahre vergangen, ein ursprünglich geplanter Blogbeitrag zum 10-jährigen Jubiläum blieb leider unvollendet in meinen Beitragsentwürfen liegen. Embarassed

Das ist nun der fünfte Zwischenbericht, oder wie man anhand des Titels bereits erahnen kann, der finale Endbericht! Die RPi-Colo bei EDIS ist nach mehr als 11 Jahren vorbei, sie wurde 2024 abgekündigt und im Dezember letzten Jahres wurde endgültig der Stecker gezogen. Das Gerät lief bis zuletzt und wurde von mir nach wie vor für die ursprünglich angedachten Zwecke verwendet. Dazwischen gab es einige Debian-Upgrades (bzw. eher Raspian-Upgrades), da zu Beginn Debian 7 (Wheezy) die aktuellste Version war. Aktuell sind wir bei Version 12, mit dem Namen Bookworm. Wie die Zeit vergeht! Shocked

Das Gerät überlebte die Heimreise von Graz nach Wien anstandslos und darf nun auf ein zweites Leben mit diversen spannenden Projekten warten. Dass es den Dauerbetrieb für mehr als ein Jahrzehnt ohne Zwischenfälle übersteht, mit einer grandiosen Verfügbarkeit, konnte ich mir damals nicht vorstellen. Umso weniger, dass die SD-Karte sowie beide USB-Sticks nicht defekt sind und weiterhin einwandfrei beschreibbar sind. Dazu ein paar Zahlen, wie viele Daten während dieser langen Zeit laut dem ext4-Dateisystem auf die Speichermedien geschrieben wurden...

Nach einem größeren Versionssprung von RackTables konnte ich seltsamerweise keine neuen Dictionary-Einträge mehr hinzufügen. Ich bekam, egal bei welchem Fantasie-String, nur noch diesen Fehler um die Ohren geworfen:

Zitat:

Database error: such record already exists

Ein ähnliches, wenn nicht sogar das gleiche Problem, ist im Bugtracker des Projekts (#2047) auffindbar, jedoch ohne Lösung.

In meinem Fall half ein Blick in die Datenbank-Tabelle Dictionary: Der AUTO_INCREMENT-Zähler wurde wohl beim Löschen von Einträgen auf einen niedrigeren Wert zurückgesetzt, wodurch das Anlegen von neuen Einträgen scheiterte.

Die Lösung ist bei MySQL/MariaDB relativ simpel...

Manche externen SATA-Controller sind schlau, zu schlau: Sie lösen bei Festplatten gerne mal nach ein paar Minuten den Spindown aus, schicken die Platten also schlafen. Das ist bei normaler Benutzung meistens kein Problem, weil sie bei neuerlicher Aktivität sofort wieder hochfahren. Bis auf ein paar Sekunden Wartezeit und einer eventuell höheren Abnützung der beweglichen Teile kein Drama. Wenn man währenddessen allerdings einen vollständigen S.M.A.R.T.-Test ausführt, wird dieser meistens ebenfalls unterbrochen!

Um dem Vorzubeugen, lasse ich bei diesen Controllern mittels screen o.ä. einfach eine kleine Schleife laufen, die andauernd für Aktivität auf der Disk sorgt...

Debian Wheezy ist völlig veraltet und erhält keinerlei Sicherheitsaktualisierungen mehr, Debian Jessie ebenso. Trotzdem kommt es selten vor, dass ich eine temporäre VM für Testzwecke mit Debian Wheezy hochziehen muss. Meistens hole ich dann mittels APT-Pinning einige Pakete aus z.B. Debian Jessie dazu.

Das Problem: APT will mir dann sofort Systemd nachinstallieren und, das ist richtig kurios, bei einem "apt-get autoremove" gleich wieder entfernen. Jedes Mal ärgere ich mich über dieses Problem und ignoriere es einfach, weil es bei einer Test-VM keine Relevanz hat. Doch für alles gibt es eine Ursache bzw. einen Workaround!

Die Lösung findet man in der Upgrade-Dokumentation von Debian Jessie...

Auf einigen Systemen liegen bestimmte Munin-Plugins bzw. relevante Dateien in Home-Verzeichnissen von Benutzern. Das ist nicht ideal, aber leider nicht ohne Weiteres zu ändern. Und jedes Mal stolpere ich über dieses Problem, dass ich mir nirgends notiert habe, wie man das löst...

Verantwortlich dafür ist (z.B. bei Debian) Systemd bzw. die Option ProtectHome im jeweiligen Unitfile. Es handelt sich dabei um eine äußerst sinnvolle Änderung! Trotzdem kann man das Verhalten bei Bedarf anpassen...