LinLog

Ah, Raymond Chen. You can always count on him for a good tip stated in a way that makes it seem blindingly obvious.

The other day I got a couple of good tips from his blog. While writing a simple batch script to wrap up executing some Selenium RC test cases, I had the need to change to another directory and then change back. A little Googling led me to this page, where Raymond expounds on the eminently useful %CD% environment variable, which stores the current directory. (Of course, I ended up just using pushd and popd, which I'd forgotten Windows had, but that's not the point.)

On the same page, Raymond links to a handy little 90-byte batch script that does the equivalent of the UNIX which command. I thought that was really great. In fact, that's something I've always wanted. I've got the UnxUtils, which includes a Windows port of which, but it's just not the same, because it requires you to specify the file extension. I'm not much of a batch scripter, so I never would have thought to even try doing that in a batch file. Go Raymond!

Here's a little problem I ran across at work the other day. I was writing a little script to SSH into our 2 app servers and restart Memcached. Simple and easy, right?

Well, not quite. When I ran the script, the restart was hanging the SSH session. The service restarted properly, but my SSH connection never closed, so the script couldn't move on to the second server. What the heck?!?

Turns out that this is an issue with the way OpenSSH handles I/O streams. Apparently the init script for starting memcached didn't close standard output, so OpenSSH stuck around waiting for it. The solution: redirect STDOUT and STDERR on the server to /dev/null. That closes the streams and keeps the session from hanging. Of course, that could be a problem if you actually need to see any of the output, but in this case, I didn't.

Yes, this is yet another "reminder to myself" Postgres post, because I've had to look this up at least 3 times.

To turn on expanded query output formatting in psql, the Postgres command-line client, run either \pset expanded or simply \x. They both do the same thing - make Postgres output each column in a result set as a separate line. This is equivalent to the mysql command-line client trick of ending the query with \G instead of a semi-colon.

Incidentally both of the above commands are boolean toggles. You run them once to turn on expanded formatting and run them again to turn it off.

So at my new job (maybe I'll post something about that later), we use PostgreSQL for our RDBMS. And, for reasons I won't get into, our application stores dates as UNIX timestamps, rather than, you know, actual dates. Thus this quick note to myself so I don't have to keep looking up how to convert between the two.

Date to UNIX timestamp in Postgres (from this page):
select date_part('epoch',now()) as unixtime; -- This will do it.
select extract('epoch' from now()) as unixtime; -- ... and so will this.

UNIX timestamp to Postgres TIMESTAMP (from this page):
SELECT TIMESTAMP 'epoch' + 1195374767 * INTERVAL '1 second';

In case there was any doubt, I'm not a hardware guy. Yeah, I can do the basics - put a PC together from parts, swap out components if something goes bad - but it's not an area where I have a lot of experience or confidence.

So what should happen to me last week? Hardware problems galore! It started with one relatively small thing and just snowballed to both the PCs in my house being more or less out of commission.

The first problem was with Sarah's PC. It would occasionally soft-lock (meaning it wasn't completely unresponsive, but wasn't operational either) and need to be rebooted. A quick inspection revealed a bunch of I/O errors. My first instinct was "bad drive", but just to be safe, I figured I'd put the drive in my PC, just to make sure the SATA controller wasn't going bad.

Good thing I did, because after some testing, it looked like it was the controller! On Sarah's PC, heavy disk activity (copying a few dozen gigs of data) always resulted in an error sooner or later. But on my PC, I never saw any problem. I even tried swapping out the SATA cable with one from my box and it didn't make any difference. So I concluded that the problem was the SATA controller.

Meanwhile, some time during this testing, one of the drives on my PC went bad! I'm assuming the problem was in the drive's controller card, because the disk was still spinning up and not making any funny noises, but the system BIOS just wasn't seeing it. In fact, when the drive was connected, the BIOS would hang on detecting it! The worst part was that it was the new 750GB drive I bought just over a month ago! On the up side, I didn't have anything irreplacable on it, and was eventually able to revive it long enough to copy most of the data off (unfortunately I didn't have enough working storage for everything, but I got the stuff I really cared about). Of course I was just past NewEgg's return window, so I had to put in an RMA to the manufacturer.

So fast-forward to this past weekend. The new $20 PCI SATA/RAID controller for Sarah's box came in. I've never dealt with an add-on SATA controller before, but it was dead simple to install - put it in the PCI slot, connect the drive, and you're done. It worked great - for one evening. Then I started seeing more disk errors. This time they were failures from ext3_find_entry() rather than generic I/O errors, but that's still not too helpful. So now I'm back to square one on that.

On top of that, I've now been seeing lock-ups on my PC. Hard locks, too, as in the system goes totally unresponsive and the capslock light starts blinking. That, for the Linux people in the crowd, indicates a kernel panic. This one was a bitch to track down, too, because it was happening randomly as I did things from within X11, but didn't seem to happen on the command line. And since kernel panic output gets dumped to the console, I couldn't see what was going on (because you can't switch from an X display to the console when the system is crashed). So I ended up leaving the system at the console and eventually got a kernel panic again. Turns out it was coming from the USB subsystem somewhere. I still don't know if it's one of my peripherals, my hub, or the USB controller, so I'll have to do some experimenting.

It's weeks like this when I really appreciate the philosophy of technical people who say, "Forget building it, just buy from a system vendor so that you can have it repaired under warranty." Fixing problems like this is sickeningly time consuming and generally not much fun. Especially if you're not a hardware guy.