Skip to content

mysqldump: Error 2020: Got packet bigger than ‘max_allowed_packet’ bytes

Für ein Zarafa Upgrade von 6.40 auf 7.1 musste ich eine MySQL Datenbank von einem alten auf einen neuen Server übernehmen. Da es sich um eine relativ große Datenbank handelte, testete ich den Vorgang vorab und alles funktionierte - inklusive dem Dump und dem Restore der Datenbank.

Beim eigentlichen Upgrade dann brach der Dump mit der folgenden Meldung ab:

mysqldump: Error 2020: Got packet bigger than ‘max_allowed_packet’

Das Problem ist, dass mysqldump nicht die gleichen Konfigurationsparameter wie der mysqld verwendet. In der /etc/mysql/my.cnf kommt ganz weit unten eine Sektion namens [mysqldump], in der man die max_allowed_packet Größe anpassen muss, wenn der Server ebenfalls größere Pakete zulässt. Passt man diese Größe nicht an, können Backups unbrauchbar sein weil sie mittendrin abbrechen.

Der Standardwert liegt bei 16M und sollte je nach Anwendung höher gesetzt werden. Bei Zarafa ist in der Regel 32M bis 64M völlig ausreichend, da die MAPI Objekte zwar größer sein können, die Attachments jedoch im Filesystem und nicht in der Datenbank liegen. Demnach muss die Datenbank meist weniger als 32M liefern.

Wenn man mysqldump von einem anderen Host aus startet (der keine my.cnf besitzt) oder die Koonfiguration nicht anpassen möchte, kann man auch als Parameter --max-allowed-packet=32M angeben. Damit wird der Eintrag in der Konfiguration übersteuert.

Chrome und Serendipity

Irgendwann nach dem ich Chrome zu meinem Standardbrowser gemacht habe, stellte ich fest, dass Serendipity beim Verfassen eines neuen Beitrags immer am Ende der Seite abstützt. Zwar nur der eine Tab (Chrome sei Dank), aber das Geschriebene war weg.

Mittlerweile weiß ich, dass es nichts mit dem Betriebssystem zu tun hat, denn es passiert unter Linux genauso wie unter Windows oder Mac OS X. Und es passiert auch über die letzten Updates von Chrome und Serendipity hinweg. Es passiert auch auf anderen Serendipity-Installationen, so dass es nichts mit einer speziellen Installation zu tun haben kann. Vielleicht hat's auch nur mit einem einzigen Plugin zu tun, das ich einsetze.

In anderen Browsern habe ich kein Problem. Aber nur um einen Blogeintrag zu verfassen muss ich jetzt einen anderen Browser starten.

Kann das jemand bestätigen?

Immer wieder super

finde ich, wenn Web Formulare nicht richtig getestet wurden. Gerade erst habe ich eine Nachfrage bei einem richtig großen Software Hersteller reingetackert und abgeschickt und bekomme

Your session expired or your user id is not registered for this module.
Please try the operation again by clicking on the tab again.
If the error persists, please contact your system administrator. 

Ist meine Anfrage nun durchgegangen oder nicht?

Error: bad minute; while reading /etc/crontab

Gerade eben stellte ich fest, dass auf einem Ubuntu 8.04 Server die Cron-Jobs nicht mehr ausgeführt werden. Also machte ich mich auf die Suche nach dem Grund, konnte ihn aber zunächst nicht finden. In der /var/log/syslog dann der erste Hinweis:

Error: bad minute; while reading /etc/crontab

Die /etc/crontab sah allerdings sehr normal aus. Da gab es keine falschen Einträge oder fehlende Angaben. Nach einigem auskommentieren und testen bin ich dann auf die Lösung gekommen. In der crontab fand ich folgende Zeile, bei der ich mir erst mal nichts dachte:

MAILTO= 

Allerdings interpretiert cron diese Zeile so, dass er MAILTO= für die Angabe der Minuten hält und danach nichts mehr kommt. Und MAILTO= ist auch keine gültige Angabe für Minuten ;-). Also entweder eine Mailadresse dahinter schreiben oder wie in meinem Falle mit einem # auskommentieren. Dann cron neustarten und schon funktionierts auch wieder.

Nervige Pidgin-Fehler

Kürzlich erzählte mir mein Pidgin, daß eine neue Version verfügbar sei und fragte mich ob ich nun die 2.4.0 herunterladen und installieren wolle. Nach einigen Tagen Sicherheitsabstand installierte ich die neue Pidgin-Version und darf mich seither über folgende, immer wiederkehrende Meldung freuen:

(07:46:05) Chris: (Es gab einen Fehler beim Empfang dieser Nachricht. Entweder haben Sie und xxxx84300 unterschiedliche Kodierungen gesetzt oder xxxx84300 hat einen fehlerhaften Client.)


Und das passiert nicht nur bei diesem einen Benutzer oder bei einem bestimmten Client. Schade drum, jetzt bin ich wieder zurück zu dem von mir eigentlich verschmähten Trillian.

tweetbackcheck cronjob