Bolivian coffee and demonic daemons

Roasting: Bolivian coffee

Bolivian seems to go directly to an oily French roast, with smoke filling the room. At least that's my experience while trying to write some simple scripts to generate random data this morning. It's probably not the fault of the beans: I was trying to slay some daemons with an irrepressible thirst for life.

You see, I'm documenting the PHP Data Objects (PDO) interface for database access, and I'm running DB2 on my system. Gotta test this stuff against a real database, you know. So as I'm running phpize to test the latest version of the PDO code, I notice it's taking a l-o-n-g time to run -- like, a minute or two rather than the 5 or 10 seconds it would normally take. WTF?

Check top. Ah, many little db2fm commands. db2fm is the DB2 Fault Monitor, a really poor man's high-availabilty tool. It's a daemon that watches your DB2 instances and automatically restarts them if they die an unnatural death -- which is fine and dandy. I don't mind that they automatically add it to /etc/inittab with a respawn parameter. Except every once in a while it goes nuts and starts burning massive amounts of CPU. I shouldn't blame it, it is a daemon after all, but when you're trying to accomplish something useful on your little laptop and you're waiting for simple commands to finish executing, it's pretty annoying.

Now, db2fm does have a command-line interface. But it's pretty cryptic:

$> db2fm -h

Usage: db2fm 

 include

-t      Unique text descriptor for a service

-i     Defines the instance of the service

-m       Specifies the location of the GCF module

-d               Brings the service down

-D               Brings the fault monitor daemon down

-k               Kills the service

-K               Kills the fault monitor daemon

What's a service versus the daemon? I dunno. I try db2fm -d, db2fm -D, db2fm -k, db2fm -K, and db2fm -d -D -k -K -- none of them actually work. I try killing the processes as root, and that's a bad idea -- they just respawn, taking more CPU slices to recover their state (ugh). Oh, duh, I comment out the /etc/inittab entry to prevent them from respawning and issue all the command variants again. No dice.

So I started roasting the Bolivian beans before this little problem-solving exercise, with the intention of having nice hot caffeine-laden coffee to help sharpen my brain to slash through layers of abstraction. Instead, at this point smoke is filling the kitchen and I realize my morning-fuzzy brain has let things get to the point that our smoke alarm might awaken the still-slumbering lady of the house. This would be bad. I kill the roaster, open the kitchen window to the -20 degree (Celsius, which everyone except denizens of a single backwards country would assume) cold, and pre-emptively silence our smoke alarm.

So now, instead of cozying up with a hot cup of coffee and my hotter wife in bed after cranking out genius code for the greater glory of PHP, I have written not a single line of code, I have oily French-roasted Bolivian beans that will produce hardly any caffeine, I've dropped the temperature of the house by five degrees, I've raised my frustration level several notches, and I've started a blog to capture this precious moment in time.


(Apologies for the quality of my first post. This ain't the original. I previewed the original, then decided to add some HTML formatting, so I switched to "Settings" where I supposedly would turn WYSIWYG on and off, and then switched back to "Posting"--where, to my horror, the post had not been saved. Twenty minutes of work gone. Sure, it's a noob move, but it never had to happen. If the text field is full of text, it's probably a REALLY good bet that your user wants to save the draft of their post. Augh. Crankiness over and out.)