How to use Conky for automatic system notification and administration

Marco Fioretti shows you how to use the Conky system monitoring tool for automatic maintenance and event notification on remote computers.

Conky is a graphical system monitoring tool for Linux. It is normally used to show all kinds of data as text or diagrams in the root window of your screen, in a much bigger and more readable format than any panel may do. As the galleries on the official website or at prove, Conky provides lots of ways to customize your desktop and impress your friends. Exchanging, tweaking, and discussing Conky configuration files can be a lot of fun if you find the most common Linux environments a bit too dull.

In general, Conky may run on one computer but appear on the monitor of another one, via SSH or Gnu Screen. Conky may also load data from plain text files of any kind, from local logs to RSS feeds or Web pages downloaded with w3m or other command line tools.

In addition to all this, Conky can be used in another interesting way that, as far as I know, has had much less coverage so far (even if the Gnu Screen trick I just mentioned uses the same technique; I'll explain in a moment). The reason is probably that Conky looks so good that most users stop there.

System administrators continuously need scripts that perform automatic maintenance and/or event notification on remote computers. In this context, a tool that is usually installed so that somebody can personally look at its output may seem useless. However, Conky has plenty of predefined variables for lots of stuff relevant for system administrators, from available disk space and CPU load to UPS autonomy and much more. Furthermore, Conky's mission is to display all this stuff in one, unified way, in order to spare people from dealing with a plethora of other, more or less disconnected tools if they want to know what's going on.

This is why, some time ago, I started to wonder if Conky might be used for automatic system administration. What if Conky could directly print all its variables to ONE file, in a format immediately usable by a shell interpreter? In that case, maintenance and notification scripts may be much quicker and easier to write, because they wouldn't have to run several unrelated commands (assuming that they are available) and format their output before deciding what to do.

Eventually, this task turned out to be much simpler than I had feared, thanks to a few Conky global settings and command line options.

A Conky configuration file consists of two parts: the first one sets general parameters, for example, which fonts should be used or where the text should be placed on the root window. The second part, that starts with the line containing the "TEXT" keyword, describes to Conky what output it should generate.

Telling Conky to print everything on the standard output is easy. First of all, run this command at the prompt:

conky -C > command_line_conky.rc

This will save Conky's default configuration in the command_line_conky.rc plain text file. Next, open that file with any text editor and set these two options as follow:

  out_to_console yes
  out_to_x no

They will force Conky to print its output to its STDOUT, but not on the X Windows screen. Once those options are set, you can save Conky's output to a file and use it in a shell script in this way:

  conky  -c command_line_conky.rc  -i 1 | sed -e 's/[ \t]*//g' > /tmp/
  source /tmp/

The first switch tells Conky to load the custom configuration file. The second makes it run only once and then quit. The sed command removes all whitespaces (more on this in a moment). As a practical example, let's assume that the output section of command_line_conky.rc looks like this:

  ROOT_SPACE=${fs_used /}
  TOP_NAME=${top name 1}
  TOP_PID=${top pid 1}
  TOP_CPU=${top cpu 1}
  TOP_MEM=${top mem 1}

The official Conky page describes syntax and meaning of all the variables I've used pretty well, so I'll directly show you the output of the commands above and only explain part of it:

  #> cat /tmp/

Thanks to Conky, we have here, for example, three MEM* variables that contain the amount of used and available memory and its percentage value. The last four lines of command_line_conky.rc, instead, return name, Process ID, CPU and memory usage of the process that is using more CPU. See what I meant? This is valid Shell code, and all it took to generate it was one Conky call! Once it has loaded this file with the source command, your script will be able to make any test you want and act accordingly.

It may, for example, kill the process whose PID is 29173 if its CPU usage ($TOP_CPU) is over some predefined value, or it may send you an email if the $MEMPERC is more than 90%, or if the root partition is almost full. There are lots of possibilities, because Conky can print in the same way lots of data. The only thing you need to be careful about is white spaces. Without the sed command, Conky would output lines like these:
  TOP_CPU=  0.00
  TOP_MEM=  0.35

that are not valid shell variables assignments because of the white spaces. Removing them with sed as I've done above is a quick but dirty solution. Sed "cleans" all lines, including those, like "UPTIME='$uptime'", that don't really need it. Should this be unacceptable, you should remove the sed command and modify command_line_conky.rc as follows:

  • put single quotes around the variables that need to keep their spaces
  • add to the definition of those that can't have spaces shell code that will remove them when is loaded. Something like this may do the trick:
  TOP_CPU=`echo '${top cpu 1}' | tr -d '[:space:]'`

With or without these extra steps, the result is always the same: Conky can provide administration scripts with lots of data to work on, in a simple way that is also quite portable, because the Conky configuration file has the same format on every system on which this utility can be compiled.