Tracking Server Uptimes

Unlike some other OS's, Linux almost never has to reboot… or so I was told when I first started learning about it. To illustrate the point, my mentor introduced me to an app that he ran on all of his servers called uptimed. It is similar to the utility that most of us have heard of, uptime, except that it runs as a daemon and logs the system's uptime instead of just reading info that is lost on a reboot. Uptimed provides a secondary command called uprecords that give statistics and makes it easy to see how long your server has been up, what the longest it has ever been up is, when it rebooted, and more.

uprecords screenshot

Until recently, I just took for granted that this wonderful app was still being maintained since it has always been available to me… enter CentOS 6. Even with the usual suspects added to my list of available repositories it was nowhere to be found. My roots are in Gentoo so I decided to take a look at its ebuild (uptimed-0.3.16-r4.ebuild) and see where they pulled it from. Based on that I was able to find the source and, sadly, find that it is not being maintained anymore. The logical solution: grab the source and build my own RPM that could be distributed where I work… that too was a no-go due to dependency on an older version of automake.

The bottom line: if you run Gentoo or Ubuntu you can still grab uptimed via your package manager. As for the rest of us, hopefully someone will read this and either decide to pickup maintenance or be able to enlighten us to a good alternative.


  • Thanks to help from a commenter below I have been able to build and install uptimed on 64-bit CentOS 6.  I am working on setting things up so I can publish my changes.
  • Source that is patched for CentOS 6 is now available on GitHub. Check out for more info.

Gene Liverman is a Systems Administrator of *nix and VMware at a university.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Uptime and rebooting the server

Anonymous's picture

I worked as an admin on Unix servers in the past and at times it was also necessary to reboot the servers regularly (weekly), as some applications and shared libraries (notoriously Motif) had memory leaks. These were "cleaned up" by the regular rebooting. I imagine there are still similar reasons today for *nix machines.

Good article

apexwm's picture

Good article, and thanks for the info. For those who commented that you should reboot a server just because, that suggestion is ridiculous. If you are using Windows, then obviously rebooting is the norm. GNU/Linux is known for long uptimes, and for a good reason: because it is way more stable than any other operating system around and doesn't need to reboot since it runs efficiently enough on its own.

People who are publicly proud

Anonymous's picture

People who are publicly proud of the uptimes on their internet facing servers are asking for a kernel exploit to be run against them.

Just cause you can run something for 660 days, doesn't necessarily mean you should. Stay up on security patches...

You want a statistic to be proud of, measure system availability using Nagios or something. See if you can pull off 99.999% a year. THAT is what Linux is good for.

Grumpy grumpster.... Let the

Anonymous's picture

Grumpy grumpster....
Let the kids have their fun. They very well could be using ksplice so no need to be debbie downer.

Ah, but ksplice doesn't check

Anonymous's picture

Ah, but ksplice doesn't check that your init scripts aren't boogered up, or that you have good mounts, or that you've fsck'd your filesystems...

Long uptimes burn you on unexpected reboots, that's my opinion at least.

Maintenance reboots

Anonymous's picture

Totally agree. There's nothing great about long uptime. Leaving a machine up for a year, you're just begging for problems when the inevitable reboot happens. Routes that weren't added statically=toast, hard drives that are on the brink=bricked, RAIDs broken, etc. I like to do a 6 month maintenance reboot whilst standing by with new hardware. I don't care about a server's stupid uptime, I care about service availability. Best to reboot in a controlled fashion than wait for your server to do it for you!

Easy to build

Anonymous's picture

I am a Slackware user and I'm use to building software from source. I use CentOS 5.x at work and we are slowly upgrading to CentOS 6. I gave it a try to build the software on CentOS 6. I ran into your issue with building it using a slightly modified spec file included in the source tarball. I quickly solved it by running "autoreconf -ivf" in the prep section. It seemed to build fine. Not sure if it actually works as I didn't install and run it.

No Luck

Gene Liverman's picture

I tried adding "autoreconf -ivf" in like you suggested but it still failed the same way. I am building with
$ rpmbuild -ba rpmbuild/SPECS/uptimed.spec
using an updated spec file. It errors out with the following:

+ make 'RPM_OPT_FLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'
cd . && /bin/sh /home/UWG/gliverma/rpmbuild/BUILD/uptimed-0.3.16/missing --run aclocal-1.10
/home/UWG/gliverma/rpmbuild/BUILD/uptimed-0.3.16/missing: line 46: aclocal-1.10: command not found
WARNING: `aclocal-1.10' is needed, and you do not seem to have it handy on your
system. You might have modified some files without having the
proper tools for further handling them. Check the `README' file,
it often tells you about the needed prerequirements for installing
this package. You may also peek at any GNU archive site, in case
some other package would contain this missing `aclocal-1.10' program.
make: *** [aclocal.m4] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.QtK6Li (%build)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.QtK6Li (%build)

Any more ideas? THANKS!

Gene Liverman is a Systems Administrator of *nix and VMware at a university.

I only get that error when I

Anonymous's picture

I only get that error when I run the spec file without the autoreconf statement. I guess for any build environment that I use I do a 'yum groupinstall "Development Tools"' to make sure I have all the normal build tools. So judging from the output of the error my best guess is that autoreconf didn't take effect.

Here is the diff from the packaged spec file for the one I used.

--- BUILD/uptimed-0.3.16/uptimed.spec 2011-09-10 15:17:50.769290112 -0700
+++ SPECS/uptimed.spec 2011-09-10 15:18:26.503222127 -0700
@@ -1,14 +1,14 @@
-%define release 1
+%define debug_package %{nil}

Summary: A daemon to record and keep track of system uptimes
-Name: uptimed
+Name: uptimed
Version: 0.3.16
-Release: %{release}
+Release: 1%{?dist}
License: GPL
-Group: System Environment/Daemons
+Group: System Environment/Daemons
BuildRoot: /var/tmp/%{name}-%{version}-buildroot
-PreReq: chkconfig >= 0.9
+PreReq: chkconfig

Uptimed is an uptime record daemon keeping track of the highest
@@ -23,6 +23,7 @@

%setup -q
+autoreconf -ivf


Otherwise, I'm not sure what the issue is other then making sure autoconf is installed. Maybe even m4 and/or automake.

I have seen the light

Gene Liverman's picture

Ahhhh... I had edited my spec file a little wrong. As you stated above, I should have had
%setup -q
autoreconf -ivf

when, in fact, I had
autoreconf -ivf
%setup -q

Thanks! I have built the x64 version, am using mock to see if the i386 version will build, and am now looking into how to sign my RPMs. Once I know this all works I will update the post with some additional details. Thanks again!

Gene Liverman is a Systems Administrator of *nix and VMware at a university.

I'm a little new myself to

Anonymous's picture

I'm a little new myself to rpm packaging but as far as I can see the setup part of the spec file is equivalent to cd directory-name.

Right now my project is getting a new rpm for ruby 1.9.2 on CentOS 5.6 and CentOS 6 and updating puppet rpm to run properly on the new ruby abi.

Updates posted

Gene Liverman's picture

Check out the updates at the bottom of the article... I have posted the fixes. Thanks again!

Gene Liverman is a Systems Administrator of *nix and VMware at a university.

My uptime is bigger than your

Paul Johnson's picture

My uptime is bigger than your uptime.