The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Wednesday, July 09, 2008

It's hard to troubleshoot when the gun is jammed …

Smirk gave me a router to configure for a customer and asked that I save the current configuration before I make any changes. It's a Cisco router, so saving the configuration is just copying it to a TFTP server. Nothing terribly hard—I already have a TFTP server installed on my workstaion, and I can easily configure the spare network port on my workstation to match one of the ethernet ports on the router, string a cable (which I already have lying around) and voilà. Nothing to it.

One Hour Later …

I'm ready to kill. I'm thinking one of (or all of) the CentOS maintainers, since I can't imagine the maintainers of logrotate, syslogd, xinetd or tftpd (is that even maintained any more?) all botching it in a perfect storm of stupidity.

tftp is controlled and run by xinetd. But the Cisco router can't save the configuration file. It's not a networking issue since I'm logged into the Cisco router over the network. The configuration in xinetd to run tftpd looks good, but what the heck, I decide to restart xinetd and check the logs anyway. That's when I find that logrogate isn't. Or rather, it is, but it's failing to tell syslogd to reopen its log files. And the configuration files for logrotate look okay as far as I can tell.

But even worse, syslogd appears to be buffering the logs in memory, maybe updating the files every 30 seconds or so. And the syslogd configuration I have specifically states otherwise. It could be that xinetd is really slow, but I have a hard time believing that it takes xinetd a full twenty seconds to digest a 13 line configuration file (and there are about 30 such files—do the math) on a 2.6GHz dual-core box—the harddrives aren't that slow (heck, Firefox comes up faster than that on this system).

Sigh.

I really hate it when the tools I expect to work don't. It's one thing to know going in that the tools don't work, or aren't there. I know I'm going to get sidetracked and can make better time estimates. It's making a time estimate expecting the tools I work with to work and then getting sidetracked debugging tool issues that pisses me off, because now I'm under a time crunch.

It's even more frustrating when the customer isn't even there to accept the router.

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.