Conspiracy of the Undead

The times when I showed off servers with 1,000 days of uptime to make my colleagues from the Windows team jealous are long gone. If I get caught with a Methuselah like this today, I can expect to answer embarrassing questions about whether I am afraid of kernel updates. (The answer to this is: Yes! I use some fairly exotic RAID controllers now because I shot myself in the foot when I updated to 2.6.27 – ouch!)

Security freaks tell scary stories about the exploits they guess will work on systems that nobody has bothered booting for a year or so. Bragging can't be the only reason why so many admins use Uptimed [1], a daemon that logs a system's uptime over an extended period of time. It makes sense for devices that are not otherwise accessible for monitoring, for reasons of location or security – you get to know exactly when the power supply last failed, or a hardware component died on you.

You can use the /etc/uptimed.conf configuration file to control Uptimed's behavior. The entry

LOG_MAXIMUM_ENTRIES=20

tells the tool to restrict the list of saved uptimes to 20 readable entries.

LOG_MINIMUM_UPTIMED=12h

lets me tell the daemon not to start writing entries until the computer has achieved at least 12 hours of uptime. This makes sense to suppress the intermezzi between two successive reboots, as would be the case if you need to repair or rebuild and try out a new kernel module (you guessed it, my RAID controllers…). You can also define milestones in the configuration file, and have the software notify you by mail when the server reaches one.

Showtime

The Uptimed package includes the Uprecords client, which exhibits the acquired data in a nicely formatted list on the console. To keep things readable, I restricted the uprecords -s -m3 output to the last three entries. There is a reason I choose my video disk recorder for this – it freezes from time to time, and I wanted Uptimed to help me discover some method to the madness of these crashes. Unfortunately, there wasn't one: I guess the hardware is broken, just as I suspected.

The Author

Charly Kühnast is a Unix operating system administrator at the Data Center in Moers, Germany. His tasks include firewall and DMZ security and availability. He divides his leisure time into hot, wet, and eastern sectors, where he enjoys cooking, fresh water aquariums, and learning Japanese, respectively.