Thursday, July 21, 2005

Apache Problem

I'm reviving my blog on my home box. I'm using Blosxom, which throws index.html files into subdirectories of the main blog. I'm using Apache, which you can tell to look for index.html if the client requests a directory. So far, so good.

I set it all up at home. My server's machine name is 'moose'. (You'll see why this matters in a moment.) I test it out; it all works. I go to work, and try it out. The main page works, but when I click on a subdir link, it pulls up a different page, namely that of Mooseworld.com. What the heck?!

Okay, right away I notice the moose connection. When I put 'moose' into Firefox's URL, it does an autocomplete thing, and I'm guessing that some DNS magic sends such a term to Mooseworld.com. But why does such a thing happen?

I search my access_log, and find that any request for a plain directory (i.e. "/foodir") returns a 301. A 301 is a redirect. Seems that Apache was redirecting to a directory with a trailing slash (i.e. "/foodir/"), which would then match its pattern for trying the default index (index.html, in my case). Only it was sending back a full URL, in my case "http://moose/foodir/".

I looked around a bit, and found that apache2.conf had a ServerName directive that was set to "moose", and when I changed it to reflect the real server name, things worked.

I'm guessing that there should be a way (perhaps with mod_rewrite?) to not require a 301 return and subsequent 2nd page request for this to work, but that'll have to wait until I convert my blog.

Wednesday, July 20, 2005

"Nobody Cared" Problem

I recently upgraded to a 2.6.11 kernel, and was getting the delightful "nobody cared" message shortly after booting up my laptop. This was preventing my combo NIC/serial PCMCIA card from working, (in particular, the NIC doesn't come up; I don't care about the serial card part). I've taken ACPI out of the kernel; several posts on the Gentoo forums pointed to ACPI as a possible culprit.

Under 2.4.x, the card appeared to run on IRQ 3; under 2.6.11, it was trying to go to IRQ 11. I started out trying to figure out how to get it back on IRQ 3, where it worked just fine.

I tried an edit to /etc/conf.d/pcmcia of 'PCIC_OPTS="irq_list=3,4,7"'. This put eth0 on IRQ3, but left ttyS1 on IRQ11. I also tried excluding IRQ 11 by adding "exclude irq 11" to my /etc/pcmcia/config.opts, which resulted in dmesg output that said that the NIC was at "io 0x300, irq 3", but below that "ttyS1 at I/O 0x2f8 (irq = 11) is a 16550A". And, I tried the "pci=routeirq" kernel boot option, to no avail.

I posted the above info to the Gentoo forums, and got a reply back from diastelo suggesting that I disable support for the serial device in the kernel. I had tried removing the 'serial' script from the boot runlevel, but that made no difference. But removing serial PCMCIA support from the kernel did the trick, and the NIC has worked fine ever since.

Monday, July 11, 2005

Out of disk space

Time for a bit of embarrassment.

I was coding merrily away in my new Eclipse 3.1, and got an error saving a source file. This is instant cause for alarm; if it has problems saving, that's really, really bad. I missed the "More Info" button on the first dialog, and ran to a shell prompt to see if the file was really corrupt.

Shortly, though, I did something to generate a "disk full" message from the command line. Harumph! Last time I looked, I had 3 or 4GB free.

(I later went back to Eclipse, got the dialog again, and clicked "More Info" to get the "out of disk space" message. For short messages like that, IMO Eclipse should just display the message, and do away with the "More Info" button.)

So, let's go find the offending file. du is your friend, and showed that my home dir housed the culprit. But looking closer, it didn't show where. All of the files and subdirs that it showed were reasonably sized, and added up to about 4GB less than the total.

Well, it turns out that du doesn't show files starting with a period, just like ls. And like ls, it has a "-a" switch to turn on display of those dot files. Grrr!

The problem was runaway messages coming out of ALSA, being put into .X.err. Something odd about a file pointer being out of sync. Yes, I should have saved the message to troubleshoot, but instead, I just restarted and have been watching ever since for .X.err to be recreated. So far, it hasn't been. (I also should have started out by restarting alsasound, rather than sacrificing 72 days of uptime, but oh well.)

As an aside, I added a line to my crontab: 0 7 * * * test -f /home/me/.X.err && echo "It's back!" This way, I'll be alerted (via email) when it returns. Hopefully, it doesn't grow to 4GB in less than 24 hours.

Sigh. Now then, where was I?