Die Fehlerbeschreibung

Beim Checkout, Update oder Export aus Subversion kamen ständig Fehlermeldungen:

svn: REPORT von »/svn/!svn/vcc/default«: Lesefehler bei Ermittlung der Blockgröße: connection was closed by server

oder

svn: REPORT von »/svn/!svn/vcc/default«: Could not read chunk size: connection was closed by server.

Das Problem ist (ungefähr) mod_auth_mysql in Zusammenhang mit einem 64bit-String. Auf diese Idee kam ich, nachdem ich ein Backtrace des Fehlers im Apache2 durchgeführt habe. Sehr spannende Sache mal so tief in die Eingeweide des Systems hinab zu blicken. Schlussendlich konnte das Problem aber identifiziert und behoben werden.

Hier eine Anleitung wie man den Fehler von mod_auth_mysql für Apache2.2 auf 64Bit-Systemen behebt (Anregungen von Stephane Chazelas):

1. Aktuelle Sourcen von libapache2-mod-auth-mysql herunterladen und bauen lassen

   apt-get -b source libapache2-mod-auth-mysql

2. sollten hierbei Fehler kommen: müssen folgende Pakete noch installiert werden

   apt-get install dpkg-dev debhelper dpatch apache2-threaded-dev

3. jetzt ins Quellverzeichnis gehen und den Patch anwenden
   (einfach in der Datei mod_auth_mysql.c die Zeile mit dem + einfügen)

   --- mod_auth_mysql.c~ 2009-01-19 14:57:14.717958623 +0000
   +++ mod_auth_mysql.c 2009-01-19 14:54:00.947332133 +0000
   @@ -49,6 +49,7 @@
   #ifdef APACHE2
   #include "http_request.h"   /* for ap_hook_(check_user_id | auth_checker)*/
   #include <apr_general .h>
   +#include <apr_strings .h>
   #include <apr_md5 .h>
   #include <apr_sha1 .h>
   #else

4. Nun nochmal compilieren

   ./configure --disable-apache13 --enable-apache2 && make

5. Apache stoppen /etc/init.d/apache2 stop
6. zuletzt die alte Datei ersetzen

   cp ./apache2_mod_auth_mysql.so /usr/lib/apache2/modules/mod_auth_mysql.so

7. Apache wieder starten und glücklich werden

Das ganze nachzuvollziehen hat mich bestimmt 2 Tage Arbeit gekostet, aber jetzt funktioniert es wenigstens alles.

Subversion hatte Schluckauf und meldete unkontrolliert: “svn: chunked stream ended unexpectedly“. Nach einiger Recherche konnte ich eine Lösung finden. Auch wenn in dem Forenbeitrag eigentlich steht, dass es keine echte Lösung ist, hat es bei mir geholfen:

SVNListParentPath on

Nun taucht der Fehler nicht mehr auf. Merkwürdig, denn eigentlich ist SVNListParentPath nur für die Darstellung des übergeordneten Hauptverzeichnisses bei mehreren parallelen Repositories da (siehe SVNBook).

UPDATE: Jetzt taucht der Fehler vereinzelt wieder auf. Das kann doch nicht sein…

UPDATE2: Fehlerquelle scheinen beim mir Encodingprobleme im Repository zu sein. Lässt sich derzeit nicht beheben.

UPDATE3: Nun gab es doch noch eine Lösung für das Problem mit chunked strem ended unexpectedly.

Subversion Logo

Jetzt habe ich ewig nach einer Lösung für folgendes Problem gesucht:

Für unser Subversion-Hosting brauchte ich die Möglichkeit die Größe des Repositories zu limitieren. Im Idealfall sollte ein Commit verhindert werden, wenn dadurch die Größe überschritten wird.

Um einen Commit zu verhindern, braucht man einen pre-commit Hook. Dieser überprüft dann ob die Größe überschritten wird und beendet sich mit Fehlercode 0 wenn alles in Ordnung war und 1 (sowie einer Fehlermeldung) wenn es ein Problem gab.

Um die Verzeichnisgröße anzuzeigen, eignet sich das Linux-Kommando du (man du). Die folgende Zeile ermittelt die Größe eines Verzeichnisses in Megabyte:

MEGS=`du -sm $REPOS | sed -r "s/^([0-9\.]+).+/\1/"`

$REPOS ist eine Variable in der für unseren Fall das Repository steht.

Hat man auf diese Weise die Größe des Repository-Verzeichnisses ermittelt, wird die Größe noch mit der erlaubten Größe verglichen und im Falle des Überschreitens eine Fehlermeldung angezeigt.

if [ "$MEGS" -gt "$QUOTA" ]; then
        #send error message to stderr
        echo "Das Repository hat die zulässige Größe von ${QUOTA}MB überschritten." 1>&2
        exit 1;
fi

via The Dumb Terminal.

Später, je nachdem wie der Service angenommen wird, werden wir das Angebot auf diverse andere Scriptsprachen (python, ruby), Deployprozesse (build management, externer deploy per scp oder ftp), Datenbanken (eXist, Xindice, postgresql, weitere SQL und XML-Datenbanken) erweitern.