Just another WordPress weblog

If you’re getting 503 errors when using varnish and everything works fine without varnish, then you may run in to the max-header-lines limit.

When looking at the output of varnishlog you might see errors like this when fetching the page from the backend:

FetchError c http first read error: -2 0 (No error recorded)

I’ve noticed that certain web software sometimes goes berserk with adding cookies (usually the same ones over and over again, so you don’t see them in your browser). But perhaps you really need that many headers. 🙂

Anyway, varnish has a default limit on the header-lines of 64. Increasing that size may help eliminate those pesky 503’s. The run-time parameter in varnish is http_max_hdr. You must set it on the command line when starting varnish. You cannot set this parameter in a .vcl file.

The syntax to set this run-time parameter to, say 256, is:

-p http_max_hdr=256

You usually add this the the start-up settings for varnish. On debian for instance, you add them to the DAEMON_OPTS in /etc/default/varnish.

This is what the varnish manual has to say about the http_max_hdr parameter:

http_max_hdr

Units: header lines

Default: 64

Maximum number of HTTP headers we will deal with in client request or backend reponses. Note that the first line occupies five header fields. This paramter does not influence storage consumption, objects allocate exact space for the headers they store.

When you get the dreaded “itunes could not backup the ipad because the backup session could not be created” error, try to powercycle your ipad first before you look into itunes. It could have saved me an evening googling and syncing in vain.

To turn off your ipad hold de sleep/wake button for a few seconds, and slide the slider to really turn off your ipad.

Turn on: hold the sleep/wake button until the apple logo appears.

If your ipad hangs while shutting down (the throbber keeps spinning) hold both the sleep/wake and the home button until the apple logo appears.

Due to a change in the lirc_dev module the LIRC driver module provided by ASRock will no longer compile / install (depending on your approach) on ubuntu kernels 2.6.32.23 that came with a recent update for ubuntu 10.40.

Make sure you use the default lirc_dev module that comes with the 2.6.32-23 kernel! Delete /lib/modules/2.6.32-23-generic/updates/dkms/lirc_dev.ko folder if it exists and run depmod -a.

To see if the new module loads run modprobe lirc_wb677 and check dmesg for errors.

Configure the lirc modules as outlined in the PDF provided by ASRock.

Update:

A compiled .ko module for the 2.6.32-24 kernel can be found here. Remove everything after the .ko and put the file here: /lib/modules/2.6.32-24-generic/updates/dkms/lirc_wb677.ko

Footnotes:

[Back to post] 1) You can safely ignore the warning generated by dpkg listed below. It must be due to do with my inferior packaging skills. Dpkg just needs to install the source code at the right location (/usr/src) and that bit works just fine.

Warning:This package appears to be a binaries-only package
you will not be able to build against kernel 2.6.32-23-generic
since the package source was not provided

Fortunately the excellent KeePass password manager has the ability to store its database on a webdrive. However, since version 2.09 KeePass changed the way it saves files to such a webdrive. Instead of just saving over the old file it first creates a .tmp file that it moves to the real file after a successful save. And that’s when the problem arises.

It turns out that renaming a file from mypasswd.kdbx.tmp to mypasswd.kdbx doesn’t play nice with the apache multiviews option. When trying to save a file to the webdav location, KeePass fails with a message like:https://kerkhove.net/some_dav_location/mypasswd.kdbx
Failed to save the current database to the specified location!
The remote server returned an error: (404) Not Found.

When looking at the apache error log it logs a line like:Negotiation: discovered file(s) matching request: /var/www/path/to/some_dav_location/mypasswd.kdbx (None could be negotiated)
The solution to this problem is to disable MultiViews in the apache config. Find the part in your config that has the “Dav on” statement and add a line like:Options -MultiViews
For security reasons you may want to add “-Indexes” there as well (and of course password protect your dav space using digest authentication).