Wandering Thoughts archives


Things not do for your network daemon's debugging option

It's always nice when people build debugging support into their network daemon. However, I have a modest suggestion:

When your daemon is designed to be run under inetd / xinetd, writing debugging output to standard error is a bad plan.

(You win bonus points for also logging it to syslog, so that an innocent person might be deluded into thinking that it's only going via syslog.)

Because, you see, all that nice debugging output is going to go flying straight off to the clients talking to the daemon. And it's unlikely to look like the valid protocol output that the clients expect. Which is likely to lead to all sorts of peculiar things happening.

Debugging mysteriously failing network daemons is hard enough without throwing even more disruptions in to clutter up the picture. So, authors of network daemons, please don't. And if you do, please document it prominently.

(And if you ever have to debug the authd daemon in Fedora Core, remember this.)

sysadmin/BadDaemonDebugging written at 16:49:29; Add Comment

The annoyance of arbitrary limits

In theory, WanderingThoughts has been syndicated on LiveJournal as the LJ user cks_techblog (here) for some time. In practice, LiveJournal has an undocumented, hard-coded limit on how large syndication feeds can be; go over the limit and LJ refuses to process your feed. Because I dislike small limits, DWiki defaults to putting lots of entries in syndication feeds, more than enough to exceed LiveJournal's size limit given how I write.

(LiveJournal compounds the problem by not allowing a syndication feed to be modified after it's created. If the feed URL could be changed, it could have been pointed at a URL that used a smaller size limit, using the /latest/<NN> VirtualDirectory form. And had LiveJournal documented the limit, I might have known to point the person who created the feed to use an URL like that to start with.)

For a long time I ignored the issue, on the grounds that it was LiveJournal's problem and not mine. But it always nagged at me, one of those little background irritations about CSpace. Today I finally gave in and created an ugly (although generalized) workaround to size-limit the syndication feeds DWiki creates for certain IP addresses.

I'm not fond of the workaround, but I'm less fond of the situation without the workaround. I've found that that's life in the real world, where clean software runs up against irritating situations and has to get its hands dirty.

Moral: please avoid arbitrary limits in your software. They are going to irritate someone sooner or later. Probably sooner than you think.

Of course, had LiveJournal avoided an arbitrary limit, or handled it better, everything could have just worked. Since LiveJournal was transferring the full syndication feed only to drop it later, it could have done something smarter, like only parse the first N kilobytes or the first 20 entries (especially since it only pays attention to the first 20 entries anyways).

(Then LiveJournal added insult to two injuries by reordering the 20 entries it picked (fortunately the top 20 entries) in some completely wacky order that is neither feed order, reverse feed order, or even chronological.)

But at least the irritation that LiveJournal was fetching a useless feed from me is now gone. That's progress, right?

tech/ArbitraryLimitAnnoyances written at 02:59:38; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.