BenBE's humble thoughts Thoughts the world doesn't need yet …

25.01.2011

SVN und seine Eimer-Brigaden

Filed under: Server — Schlagwörter: , , , , , — BenBE @ 22:06:29

Die wohl mysteriöseste Fehlermeldung, die mir beim Apache bisher untergekommen ist (abgesehen von nichtssagenden SegFault-Meldungen, wenn plötzlicher Kindstot auftritt, liefert das SVN-Modul, in Verbindung mit WebDAV. Glaubt ihr nicht?

Dann werfen wir doch einmal einen gespannten Blick auf folgenden Auszug des Error-Logs:
[Tue Jan 25 21:01:29 2011] [error] [client 1.3.3.7] (11)Resource temporarily unavailable: Could not get next bucket brigade (URI: /tnk/!svn/wrk/3cd88c65-3133-4b94-9a4e-4bfb50692b81/trunk/some/file/propably/involved.here) [500, #0]
[Tue Jan 25 21:01:33 2011] [error] [client 1.3.3.7] Unable to PUT new contents for /tnk/!svn/wrk/3cd88c65-3133-4b94-9a4e-4bfb50692b81/trunk/some/file/propably/involved.here. [403, #0]
[Tue Jan 25 21:01:33 2011] [error] [client 1.3.3.7] Could not prepare to write the file [500, #160044]
[Tue Jan 25 21:01:33 2011] [error] [client 1.3.3.7] Cannot write to the prototype revision file of transaction '42-1j' because a previous representation is currently being written by this process [500, #160044]

Ich habe von der Person, die diesen Fehler – fast schon regelmäßig, hab ich mir sagen lassen – bekam, auch schon mehrfach Hinweise auf das Vorhandensein dieses Fehlers bekommen. Einzig das Finden einer Lösung war bisher immer recht schwierig, weil auf meinen Repositories, die auf dem gleichen Server liegen, nichts von all dem reproduzierbar war.

Gut. Heute trat das Problem wieder einmal auf, diesmal hatte ich aber bei Google ausreichend Glück und fand da was. Sieht auf den ersten Blick erst einmal unscheinbar aus, aber GENAU hier passten zwei Dinge zusammen: Der Beschuldigte wollte große Dateien hochladen und die Fehlermeldung. 😉

Anhand des Links war das erste Problem auch bereits recht schnell identifiziert. Wie im Link beschrieben wurde zuerst

LimitXMLRequestBody 0

und danach

LimitRequestBody 0

ausprobiert. Damit ging schon mal ein erster Teil des Commits durch: Der kleinere von beiden.

Für den größeren war nun etwas Raten angesagt, da viele Module aber keine Limits setzen, war (abgesehen von mod_fcgid, was für FCGI-Anfragen ein Limit erzwingt) erstmal nur mod_reqtimeout auf der Liste der Verdächtigen. Also kurz mit

a2dismod reqtimeout
apache2ctl restart

und auf den nächsten Anlauf gewartet. Nach mehr als 5 Minuten war auch dieser abgeschlossen: Diesmal komplett OHNE Fehlermeldung.

Da mod_reqtimeout nun auf seine Art abgebrochene oder andere tote Verbindungen beseitgt, kann ich auf einem Live-System nur schlecht darauf verzichten. Ein Anheben der Grenzwerte sollte aber dennoch ähnliche Erfolge zeigen:

<IfModule reqtimeout_module>
 
# mod_reqtimeout limits the time waiting on the client to prevent an
# attacker from causing a denial of service by opening many connections
# but not sending requests. This file tries to give a sensible default
# configuration, but it may be necessary to tune the timeout values to
# the actual situation. Note that it is also possible to configure
# mod_reqtimeout per virtual host.
 
# Wait max 20 seconds for the first byte of the request line+headers
# From then, require a minimum data rate of 500 bytes/s, but don't
# wait longer than 40 seconds in total.
# Note: Lower timeouts may make sense on non-ssl virtual hosts but can
# cause problem with ssl enabled virtual hosts: This timeout includes
# the time a browser may need to fetch the CRL for the certificate. If
# the CRL server is not reachable, it may take more than 10 seconds
# until the browser gives up.
RequestReadTimeout header=20-600,minrate=500
 
# Wait max 10 seconds for the first byte of the request body (if any)
# From then, require a minimum data rate of 500 bytes/s
RequestReadTimeout body=10,minrate=500
 
</IfModule>

Letzten Neustart eingelegt und jetzt heißt es abwarten, ob die Konfig hält.

Flattr this!

3 Comments »

  1. Hallo
    habe neuerdings auch diese Fehlermeldung auf einem kleinen NAS der als DAV-Server dient. Der Fehler tritt auf, wenn größere Musikdateien (eigene Musikaufnahmen .wav, ab 400MB) auf den Server hochgelanden werden. Ich bin an und für sich Laie, habe es aber hinbekommen, auf besagtem NAS ein Debian mit Apache zum laufen zu bekommen. Das System läuft nun schon seit ca. 2 Jahren und hat derartige Zicken noch nie vollbracht. Regelmäßig Updates sind natürlich obligatorisch. Du scheinst eine Lösung gefunden zu haben. In welcher conf trägst du obige „LimitXMLRequestBody 0“ und „LimitRequestBody 0“, sowie die Direktive zwischen IF-Module ein. Brauchst du noch zusätzliche Angaben zu meinem System?

    Grüße

    Martin

    Kommentar by Martin — 19.09.2011 @ 23:11:48

  2. Hallo
    bei mir taucht auf meinem dav-server (Debian Squeeze auf NAS sheevaplug) bei größeren Dateien (eigene Musikdateien ab ca. 400 MB?) der gleiche Fehler auf. Der Upload von großen Dateien wird neuerdings! unterbrochen und die genannte Fehlermeldung erscheint in den Logs. Bis vor 4 Monaten war dieser bug? nicht vorhanden.
    Ich bin kein IT Experte, eigentlich nur Laie und habe das System stur nach Anleitung zum Laufen bekommen. Das NAS mit dem Server läuft seit zwei Jahren problemlos, ist meine private Cloud und wird stets upgedatet, aber in welcher conf nimmst du obige Einträge vor? Auf dem Debian läuft ein Apache2. Dort laufen wiederum zwei virtuelle Server, mit bekanntermaßen eigenen confs. Was brauchst du noch für Angaben von mir?
    Grüße
    Martin

    Kommentar by Martin — 19.09.2011 @ 23:22:17

  3. Der „Bug“ resultierte aus einer Änderung an der Default-Konfiguration des Apache irgendwann zwischen Squeeze und Testing. Um den Server besser vor DoS-Angriffen zu schützen, wurde die Request-Größe beschränkt, um sehr große Anfragen, die den Server stark belasten zu reduzieren.

    In meinem Fall stehen die überschriebenen Werte (also besagte zwei Direktiven) beide in /etc/apache2/mods_available/dav_svn.conf (Einfach am Ende der Datei ergänzen). Jede andere Datei, die als Teil der Apache-Konfiguration gelesen wird (z.B. die apache2.conf würden aber genauso funktionieren.

    Der zweite Teil bezieht sich auf mod_reqtimeout, dürfte also im Normalfall keine Rolle spielen, weil dieser nicht in der Default-Konfiguration auftaucht IIRC. Ansonsten einfach die /etc/apache2/mods_available/reqtimeout.conf entsprechend anpassen.

    Kommentar by BenBE — 20.09.2011 @ 20:32:15

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress