A Day Late

I learned the benefit of using the “straight_join” keyword while working on a complex query at work today. For some reason the query would only complete if I was running it on the mysql client on the mysql server. All remote connections would simply die. Actually they didn’t die, they would hang. I watched the processlist as the query was running. The status indicated “copying to tmp table”. Eventually the query would disappear from the processlist but no results or information would return and the client appeared to still be waiting for a response. I tried increasing the tmp_table_size variable but that didn’t help. I suspect it has something to do with the tmp directory (possibly not enough space available or something like that).

Anyway, I was able to work around the problem by rewriting the query using the straight_join keyword. Apparently MySQL isn’t necessarilly good at choosing the join order in complex queries. By specifying a complex query as a straight_join the query executes the joins in the order they’re specified. By placing the table I assumed to be the least common denominator first and specifying straight_join I was able to improve the query performance by a few minutes. The new query also completed successfully on the remote clients. Now…if I could just figure out why the first query hung.

When I reconfigured my server using Debain I wanted the same harddrive raid setup I had with Redhat. Basically a completely redundant file system that would boot off either drive in the event of a failure. I found a number of howto’s (this one, and this one). I followed both instructions but still could not get the system to boot. I was 95% sure it was a problem with my initrd.img file since I was getting cramfs errors and a kernel panic with “kill init”. So, for the benefit of those who have the same problem, here’s what I did.

(more…)

src="http://www.w3.org/Icons/valid-xhtml10"
alt="Valid XHTML 1.0!" style="margin:5px" height="31" width="88" border="0" align="right" />
src="http://jigsaw.w3.org/css-validator/images/vcss"
alt="Valid CSS!" align="right"/>
I spent a little time running this page through some web standards validators last night. I was curious to know how much work it would take to validate it with XHTML 1.0 and CSS. Surprisingly it didn’t take much. A half hour after I started I was done. I also decided to run it through a 508 standards validator (accessibility), it passed on the first run. For those that are interested, I added the validator links to the bottom of the right menu.

If you’re in the root folder of your filesystem, don’t type grep -r “some stuff to search for” *. Why? Because you’ll get a message like “grep: memory exhausted” and your system won’t respond (at least it won’t respond to ssh, http, smtp, etc). Actually, it appears it just crashes the network port. Executing a simple ifdown eth0 followed by an ifup eth0 from the console appeared to solve the problem. Then again, if you’re like me and your server is housed 20 minutes away and this happens at midnight it’s a little inconvenient to go access the server.

Why does this happen? Well, apparently grep keeps appending to its buffer until it comes across a newline character ‘\n’, at which point it clears the buffer and starts reading from the next line. This is a problem when it tries to search a large binary file (like something in /dev or /proc). I should have known better and excluded /dev and /proc to begin with, or even better run the command inside a subfolder such as /etc (which is probably all I needed to search). I’ll remember that next time. Still, after this, I’m nervous about executing a grep command. What if it comes across some large binary file I didn’t anticipate. I’m thinking of writing a simple shell script and add it to cron to run every fifteen minutes to cycle the network interface if it can’t ping the gateway. I think that should take care of it, but that solution seems a little hackish. Anyway, I’m open to suggestions for a better one.

I finally got around to making some upgrades and changes I’ve been planning for a while. Since I reached the end of life cycle for Redhat 9.0 and I wasn’t interested in moving to Fedora, I decided this was a good time to move to Debian. Initially I planned to bring up a temporary system while I rebuilt the main server but I decided I might as well just get it over with. So, after I backed up the server I wiped it clean and started from scratch.

The installation was a little tricky since I was using a multiprocessor system with a RAID 1 setup (software). Getting both processors working was simple. I used apt-get to install the SMP kernel and that was it. The RAID was quite a bit more involved and troublesome but I’ll save that “Howto” for another time.

For the most part I’ve built the system using the debian packages. I wanted to use Exim as my SMTP server but I also wanted it to use MySQL to store the configurations for virtual domains and email usernames. Since that wasn’t possible with the Debian Exim package I built it from source by following these instructions. I also built Qpopper from source using the same instructions. The instructions are ok but seemed a little incomplete at parts. Basically I just looked at the Exim and Qpopper configuration files (included at the end of the instructions), commented out the Amavis sections and that was about it. It’s working perfectly.

I also made some changes to my Url’s. I moved my weblog from http://www.daylate.com/blog/ to http://www.daylate.com/. So basically that URL is for my blog. I also have another URL, http://www.jwholmes.com where I moved my picture gallery and such. The best thing is, all the old links work, thanks to mod_rewrite.

So, if you’ve noticed the site has been down a little bit in the past week, this is why. Now that I’ve worked through all the kernel issues it should be up and running for a long time (I hope, knock on wood). Debian really is cool, by the way.