« The reasons I like Mac on Intel | Main | The way packaging should be »

When kill doesn't do what you tell it and dmesg is crap (OS X/Tiger/10.4 Problems)

There is only one thing I disdain more than any other programming snafu: kill not being able to kill a rogue process. Friday, in a hurry to get out of the office, I was messing with a USB-to-EIDE converter from Wiebetech, trying to get data from what appears to be a long-gone hard drive back from the dead. I just installed a Fujitsu ScanSnap on my G5 at work and somehow mangled the USB hub so that all of the attached devices went dead. One of them was the ScanSnap. No worries, right? USB is hot-swap and the devices should come back alive when I unplug the hub and re-plug everything. Wrong. For some reason, the resident driver for the ScanSnap hung and I could do nothing to kill the application. I tried forcing quit through the normal routines via the gui (in OS X Tiger). After waiting and clicking and waiting, I finally opened up the terminal, found the process number (ps aux | grep Snap) and ran 'sudo kill pid' again and again and again. It never worked. The process kept hanging. Besides wanting to kick my machine or hit it with a hammer, I was at a loss. How the heck can a process get so stuck that kill won't even kill it? (My guess has to do with shoddy programming.) If I actually had the time, I would have tried to trace the problem, but I didn't and ended up hitting the power switch. The beauty of unix is that you are supposed to be able to cleanly kill processes that won't shut down or are becoming problematic, without affecting the overall system. (The reason I dislike using Windows so much is it is prone to crashing due to a program malfunction than due to something deeper in the system.) My second and last question is how in the world the software engineers came up with the brainstorm that dmesg would only keep track of the last 100 or so system events and no more? What the hell is that? dmesg is one of the most useful utilities that I use to figure out where I went wrong with something - e.g. why the USB-to-EIDE converter wasn't working. If it shows me only the last 100 events and stuff is happening so quickly to the system, what good does it do for troubleshooting.
I guess there are two things I find overly irritating: programs not kill'ing and dmesg being worthless because an engineer decided its output was too long. Too bad a hammer won't solve either problem and too bad OS X sometimes shows its bastardized state of unix-ness.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)



About

This page contains a single entry from the blog posted on January 15, 2006 6:09 PM.

The previous post in this blog was The reasons I like Mac on Intel.

The next post in this blog is The way packaging should be.

Many more can be found on the main index page or by looking through the archives.

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.33