HAPPYTEC.at :: Blog

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...

Nach einem Upgrade von Debian Stretch auf Buster und direkt weiter auf Debian Bullseye, sah ich mich am Wochenende mit einem völlig neuen Problem konfrontiert: Das (Neu-) Starten des Munin-Nodes dauerte ewig und lief sogar in ein Timeout. Systemd versuchte danach quasi im Minutentakt, den Dienst hoch zu bringen, was immer wieder scheiterte. Grafiken dieses Nodes wurden dementsprechend keine mehr generiert.

Die grundlegende Ursache: Ich verwende auf diesem Host sehr viele snmp_* Plugins, von denen aber einige Hosts nicht 24/7 laufen. Beim Starten von munin-node werden alle Plugins einmal mit "config" initialisiert. Das dauert so schon relativ lange, aber noch länger, wenn bei allen Hosts, die offline sind, jeweils auf ein Timeout gewartet werden muss. Wenn das insgesamt länger dauert, als Systemd bereit ist zu warten, bekommt man ein Problem. Durch den andauernden Neustart des Dienstes kann dieser die Initialisierung niemals vollenden und steht nicht zur Verfügung...