Re: Sporadic Tux Failures
"William M. Shubert" <[email protected]> Sat, 17 Jun 2006 17:40:23 -0700
| Newsgroups | gmane.network.tux |
|---|---|
| Message-ID | <[email protected]> |
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!