Sending alerts to your Linux desktop when things go wrong

I run gnome on my work desktop, and even with our various monitoring solutions I still use some custom notification tools to get alerted when specific issues occur. One of these tools is gnome-notify, which allows you to create a visible notification inside your desktop workspace. This tool has several useful options, which are displayed when you run notify-send with the “-?” option:

$ /usr/bin/notify-send -?
  /usr/bin/notify-send [OPTION...]  [BODY] - create a notification

Help Options:
  -?, --help                        Show help options

Application Options:
  -u, --urgency=LEVEL               Specifies the urgency level (low, normal, critical).
  -t, --expire-time=TIME            Specifies the timeout in milliseconds at which to expire the notification.
  -i, --icon=ICON[,ICON...]         Specifies an icon filename or stock icon to display.
  -c, --category=TYPE[,TYPE...]     Specifies the notification category.
  -h, --hint=TYPE:NAME:VALUE        Specifies basic extra data to pass. Valid types are int, double, string and byte.
  -v, --version                     Version of the package.

To use this tool to send an alert when a fault is detected, I typically wrap some conditional logic to parse the output of one or more commands:


if [ "${system_check}" = "1" ] then;
    /usr/bin/notify-send -t 10000 -u critical "Problem with server X"

The code above will run the command embedded inside $(), and capture the output from this command in the variable system_check. If the value of the output is 1, then notify-send will be invoked to send a notification with the string “Problem with server X” to my desktop. The real value of notify-send comes when you combine it with the clusterit tools, and generate notifications based on the result of running a command across ALL of your servers. Nice!

Switching between the KDE and GNOME window managers on Centos and Fedora Linux hosts

I recently switched a Fedora host from the GNOME window manager to KDE. This exercise allowed me to familiarize myself with how X and the various window managers are organized on Fedora hosts, and I thought I would jot down how to switch between window managers for future reference.

When a Fedora host is booted into run-level 5, the following initab entry will cause the X server and Window manager to start:

# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon

The prefdm script uses the /etc/sysconfig/desktop file to control which window manager (KDE or GNOME) is started, as you can see in the following code snippet from the script:

if [ -f /etc/sysconfig/desktop ]; then
        . /etc/sysconfig/desktop
        if [ "$DISPLAYMANAGER" = GNOME ]; then
        elif [ "$DISPLAYMANAGER" = KDE ]; then
        elif [ "$DISPLAYMANAGER" = XDM ]; then

So to set the default window manager to GNOME, you can set the DISPLAYMANAGER variable to GNOME:

$ echo “DISPLAYMANAGER=GNOME” >> /etc/sysconfig/desktop

To use KDE, you can set the DISPLAYMANAGER variable to KDE:

$ echo “DISPLAYMANAGER=KDE” >> /etc/sysconfig/desktop

I dig the fact that Fedora and CentOS Linux servers control application settings through configuration files in /etc/sysconfig. This makes it easy to adjust application settings, and ensures that a package update won’t whack your customizations! Nice!

Restarting X and the GNOME window manager on Linux hosts

I useGNOME as my primary desktop at work, and periodically need to restart the Xserver / windowing environment to pick up new changes. If I have an X environment up and running, I will send a cntrl + alt + backspace to restart the X server. If for some reason I’m not able to send the key sequence above (this isn’t feasible if I’m logged in remotely), I will run the telinit command to switch to run level 3 (multi user mode w/o X), then execute it a second time to switch back to run level 5 (multi user mode w/ X):

$ telinit 3

$ telinit 5

The latest GNOME bits are pretty slick, though I’m starting to dig KDE again (I used to use KDE years ago). I plan to share my experience with the latest KDE bits in a future post.