Whoopsie Ate My Server RAM?!? (An Ubuntu Tweak)

Whoopsie is Ubuntu’s automated error tracker submission daemon, it’s Wiki page says:

Ubuntu’s error tracker explains crashes, hangs, and other severe errors to end users; lets them report an error with the click of a button;

(emphasis, mine)

Which, certainly sounds like a good idea — with two minor drawbacks:

a) Ubuntu Server has no “buttons” to click.

b) Reporting “end-user formatted errors” on a Server is probably not useful — now, it might just be me, but seeing:

Apache has crashed


child pid 7716 exit signal Segmentation fault (11)

the latter is probably more useful to diagnosing the problem that caused the signal 11 in the first place.

Now to be fair to Ubuntu, the “Apache has crashed” error doesn’t really exist as a current error exhibited from the Whoopsie daemon, but that’s not the point of this post — which is actually the large amounts of system memory that it seems to use by default.

In addition, i’d suggest that on a desktop installation the Whoopsie daemon is actually quite useful, especially for non-technical end-users and first time Linux users (there are exceptions, such as the consistant crash that occurs on the Unity desktop environment on Ubuntu 12.04 or 12.10).

However, we’re talking about servers in this instance, where the same rules do not generally apply.

So, moving right along…

Compare the following two screenshots, which are examples from one of our running machines, the first with Whoopsie running on an installation running nginx and varnish — but it’s otherwise a barebones installation, just web software, no PHP, no SQL, no DNS.

htop, showing our pre-removal position.

Using htop, this is our install pre-removal.

The second, after purging the whoopsie program from our Ubuntu installation.

htop, showing our post-removal position.

Again, using htop, this is our install post-removal.

183M of Virtual RAM (vmsize) for a daemon we’ll never use, seems excessive.

Of course, using the incredibly useful smaps.pl script by Ben Maurer, we can see a much more detailed breakdown of the memory used by Whoopsie — both those that are shared with other processes on the system, as well as those that are exclusive to the particular program we’re looking into.

To run Smaps.pl

If you’re interesting in duplicating the tests described in this post, you’ll need to do the following:

a) the actual script, which doesn’t seem to exist on Ben’s original page, but you can find with a little searching through the interschnizel.

b) and, if you don’t already have it make :

# apt-get install make

c) then, simply install the required perl modules using CPAN, like:

# cpan App::cpanminus
# cpan Class::Member
# cpan Linux::Smaps

Once we’ve done all that, simply run:

# perl smem.pl <process ID>

(Obviously, if you’re not actually building binaries on your server, you should either remove the make software when you’ve completed your tests, or better, install a copy of your installation under virtualisation and run your tests there.)

So, if we now go ahead and analyse the amount of memory that the whoopsie daemon is actually using a total of 4.3M of RAM and we also find libgobject, x509, heimdal, SQLite and a number of other libraries that are, frankly un-needed on a server that is only serving static pages from a lightweight HTTP server.

smaps.pl showing a breakdown of the Whoopsie process.

Smaps.pl’s view of the Whoopsie process (trimmed to the first 25 lines).

It looks even worse, especially when the static webserver has a total vmsize of 31M and is only using 996kb of RAM of it’s own accord.

smaps.pl showing a breakdown of the NGiNX process.

Smaps.pl’s view of the NGiNX process.

So, in order to save yourself a little RAM on a server installation of Ubuntu — especially if you are running a low-memory system, are experiencing swappiness issues, or just want to have a leaner system.

# apt-get purge whoopsie libwhoopsie0