Home ›

Tracking Server Uptimes

Sep 08, 2011  By Gene Liverman
 in

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.

UPDATES: 

  • 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  uptimed.technicalissues.us for more info.
______________________

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

Comments

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
Submitted by Anonymous (not verified) on Wed, 09/14/2011 - 17:32.

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
Submitted by apexwm on Tue, 09/13/2011 - 08:02.

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
Submitted by Anonymous (not verified) on Fri, 09/09/2011 - 00:12.

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
Submitted by Anonymous (not verified) on Fri, 09/09/2011 - 09:33.

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
Submitted by Anonymous (not verified) on Mon, 09/12/2011 - 09:32.

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
Submitted by Anonymous (not verified) on Mon, 09/19/2011 - 17:52.

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
Submitted by Anonymous (not verified) on Thu, 09/08/2011 - 23:31.

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
Submitted by Gene Liverman on Fri, 09/09/2011 - 15:30.

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
Submitted by Anonymous (not verified) on Sat, 09/10/2011 - 17:34.

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
-Source: http://prdownloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz
+Group: System Environment/Daemons
+Source: http://podgorny.cz/uptimed/releases/%{name}-%{version}.tar.bz2
BuildRoot: /var/tmp/%{name}-%{version}-buildroot
-PreReq: chkconfig >= 0.9
+PreReq: chkconfig

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

%prep
%setup -q
+autoreconf -ivf

%build
%configure

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
Submitted by Gene Liverman on Sun, 09/11/2011 - 21:36.

Ahhhh... I had edited my spec file a little wrong. As you stated above, I should have had
%prep
%setup -q
autoreconf -ivf
when, in fact, I had
%prep
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
Submitted by Anonymous (not verified) on Mon, 09/12/2011 - 14:01.

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
Submitted by Gene Liverman on Sat, 09/17/2011 - 19:46.

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
Submitted by Paul Johnson (not verified) on Thu, 09/08/2011 - 21:07.

My uptime is bigger than your uptime. http://ursamundi.org/cgi-bin/uprecords.cgi

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState