Thinking about the implications of your program being successful

Recently, some of our Red Hat Enterprise Linux systems started mailing us a message from cron once an hour:

/etc/cron.hourly/mcelog.cron:

mcelog: warning: record length longer than expected. Consider update.

There are two things wrong with this message. The first is a RHEL bug; Red Hat should have made sure that this cron job didn't bombard sysadmins with unimportant messages by, for example, redirecting standard error to /dev/null.

(This is sadly a general problem that RHEL has; there seem to be any number of cron entries that will spray you with email if you let them, and some of them are installed by default.)

The second, though, is that the author of mcelog hasn't thought through the implications of it being a successful Linux program, which it clearly is. In Linux, your program is a success if it's important enough to be packaged by distributions and even more of a success if they start installing it by default, as has happened with mcelog on at least RHEL.

When your program is packaged and installed by Linux distributions, ie when it is a success, it is essentially pointless to suggest to people that they install an updated version by hand; it just doesn't happen. Sysadmins won't don't do that unless we absolutely have to, and most other users are just going to look at you blankly at the very suggestion. Once a program comes from a distribution package, that's pretty much it; either the distribution updates it or no one does.

Before mcelog became a success, this message was a perfectly sensible suggestion; people were building their own copy anyways, so telling them to update it was fine. But the more successful mcelog became, the more that people got it from their distribution instead of by building it themselves, the more the suggestion turned into something that almost no one was going to follow and thus became useless noise.

(In practice the net effect of this message was to get me to run 'rpm -e mcelog' on the affected machines.)