Sporadic Tux Failures

William M. Shubert wms at igoweb.org
Sun Jun 18 00:40:23 UTC 2006


On Sat, 2006-06-17 at 16:26 -0700, Carlos Averett wrote:
> I've currently got lighttpd serving the dynamic content, and am trying
> to get tux to serve all the static content (gifs, jpegs, css, etc).
> For some reason, tux randomly hands off files to the userland HTTP
> server, causing this setup to break.  It's not particularly
> consistant, either.
> 
> For example, I have a test page with 4 gifs, and a .css file.  Every
> time I reload, some of the images/css don't load, while others do.
> Each reload brings a new page, as I never know what will actually be
> handled by tux, and what will be passed on.
> 
> I've read through the documentation, and have tried disabling
> keep-alives, to no avail.  Has anyone else experienced this problem,
> and been able to resolve it?

You mean that you will reload a page, and the files handled by tux
changes with each reload? Or is it reliable, "xxx.gif" is always handled
by Tux, while "yyy.gif" is always handled by lighttpd?

If the former, then the only thing I can think of is keep-alives. Try
using something like wget, fetching each file with a separate instance,
and if that forces all files to be tux, then you know it is the
keep-alives. If it is *still* unreliable whether xxx.gif gets loaded by
tux or lighttpd, then you have a real mystery on your hands!

If the latter, then just look very carefully for differences in the
files. Tux is picky about protection flags, that may be it, or if you
have symbolic links it is possible that a link leads out of tux's root
area.

At one time I was having issues so I instrumented Tux with printk()
calls at each decision. It was very helpful in clearing up mysteries
like this. I don't have that copy of Tux around any more, but it is easy
to make - Tux isn't very big, so instrumenting each decision only takes
about 15-20 minutes to do. Then compile, install, and run your test, and
the mystery will be solved. Make sure you put back standard Tux
afterwards, or your kernel logs will quickly fill up your whole disk
once you enter production!




More information about the tux-list mailing list