Spaß mit pymysql
19. Mai 2020 um 17:51 Uhr von Atari-Frosch
Ihr kennt das ja schon, wenn ich „Spaß mit $irgendwas“ in die Überschrift schreibe, hat mal wieder was nicht funktioniert, wie es sollte oder wie ich mir das dachte. In diesem Fall gab's aber tatsächlich eine recht schnelle Lösung.
Kürzlich habe ich auf zwei Servern ein Upgrade auf Devuan Beowulf durchgezogen. Dann entdeckte ich jeweils im daemon.log Einträge, die mir gar nicht gefielen:
Und das alle paar Minuten seit dem 14. Mai früh morgens. Die Auslöser dieser Meldungen waren aufgrund der Zeitstempel schnell gefunden: Zwei per cronjobs aufgerufene Python-Scripte von mir, mit denen ich aus den Datenbanken der ClassicPress-Installationen unterschiedliche Daten aus den Wordfence-Tabellen auslesen lasse. Das eine wird alle fünf Minuten aufgerufen und greift bei jedem Aufruf in alle konfigurierten Datenbanken, das andere wird getrennt nach Blogs ein- bis zweimal pro Tag aufgerufen.
Ein wirkliches Problem schien aber gar nicht vorzuliegen, denn die Scripte bekamen nach wie vor die gewünschten Daten. Trotzdem wollte ich die Meldungen nicht ignorieren; es könnte ja etwas sein, was erst einmal keine sichtbaren Probleme macht.
Allerdings fingen die Meldungen nicht erst mit dem jeweiligen Upgrade an, sondern bereits vorher. Das schien es erst einmal komplizierter zu machen.
Um herauszufinden, was sich geändert haben könnte, durchforstete ich das history.log von apt. Und siehe da:
Commandline: /usr/bin/apt-get -o quiet=1 dist-upgrade -y -o APT::Get::Show-Upgraded=true
Upgrade: mariadb-common:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), mariadb-server-core-10.3:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), mariadb-server-10.3:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), galera-3:amd64 (25.3.28-stretch, 25.3.29-stretch), mysql-common:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), mariadb-client-10.3:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), mariadb-server:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), mariadb-client-core-10.3:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), mariadb-client:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), libmariadbclient18:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch), libmariadb3:amd64 (1:10.3.22+maria~stretch, 1:10.3.23+maria~stretch)
End-Date: 2020-05-14 04:09:26
Kurz: MariaDB bekam ein Update von Version 10.3.22 auf die Version 10.3.23. Und seitdem war es nicht mehr so ganz mit meinen Scripten einverstanden. Nur: Warum?
Mark Nowiasz brachte mich auf den richtigen Weg (danke hier nochmal): MariaDB: (Got an error reading communication packets). Ich fasse das hier nochmal zusammen:
Zielführend war seine Rückfrage: „Vielleicht ist MariaDB da strenger geworden? Schließt denn das Python-Skript die Verbindung ordnungsgemäß?“
Die beiden Scripte verwenden dieselben Code-Zeilen, um die Daten abzugreifen. Die sahen bisher so aus:
sql += " WHERE id > " + str(lastattackid) + " AND actionDescription != 'None' ORDER BY ctime"
db = pymysql.connect(dbhost, dbuser, dbpass, dbname)
cursor = db.cursor()
cursor.execute(sql)
sqlresults = cursor.fetchall()
Mark hat natürlich Recht: Ich hatte die Datenbankverbindung nicht ordnungsgemäß wieder geschlossen. Bis zur 10.3.22 hat sich MariaDB daran nicht gestört bzw. es hat das nicht angemeckert. Beim Überfliegen habe ich im CHANGELOG nichts gefunden, was das erklären könnte; wobei dieses Log jetzt nicht wirklich „mal eben“ gelesen werden kann, da muß man eigentlich mehr Zeit investieren.
Ich suchte und fand die Python Database API Specification v2.0 und darin die Spezifikation zum Schließen von mysql-Datenbanken, verstand sie aber erst nicht ganz richtig und ergänzte den obigen Code-Block mit einem
Auf Marks zweiten Hinweis hin änderte ich das ab in
– und seitdem kommen keine Fehlermeldungen mehr 🙂
Kurz: PEBKAC. Das Update auf MariaDB 10.3.23 machte einfach nur meinen bisherigen Fehler, daß ich die Verbindungen nicht ordnungsgemäß geschlossen hatte, sichtbar.