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

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.