Use Nagios to Check Your Zypper


If you use Nagios to monitor your system and run openSUSE on a remote server the bash script presented here will check for online updates and is designed to be run by Nagios so that the result will appear on the Nagios service-detail page.

The script is pretty unsophisticated as it just parses the output from the zypper command. A more sophsiticated solution might interact directly with libzypp, the library that provides zypper with its functionality. Of course, that's not possible using bash. Based on a quick scan of the libzypp documentation it appears the only current option for doing that is C++.

A Nagios plugin script outputs information in two ways:

  • It writes a short status message (one line of text) to the standard output which Nagios displays on the service-detail page.
  • It sets its exit status to indicate to Nagios the status of the service:
    • 0 if the service status is "OK"
    • 1 if the service status is "WARNING"
    • 2 if the service status is "CRITICAL"

If you run zypper from the command line you will see output similar to the following:

  $ sudo zypper list-updates
  * Reading repository 'openSUSE-10.3-Updates' cache
  * Reading repository 'Main Repository (OSS)' cache
  * Reading repository 'Main Repository (NON-OSS)' cache
  * Reading repository 'Packman Repository' cache
  * Reading installed packages [100%]

  Repository:           | Name             | Version | Category | Status
  openSUSE-10.3-Updates | dhcpcd           | 5390-0  | optional | Needed
  openSUSE-10.3-Updates | openmotif22-libs | 4540-0  | optional | Needed
  openSUSE-10.3-Updates | ruby             | 5483-0  | security | Needed

The script looks for the "----" line and then breaks the subsequent lines into fields, using the "|" as the separator character. Using this data it then builds the output text and sets the status. The status is set to 0 if there are no updates available, 1 if there are updates available, and 2 if any of the updates are security related.

Running zypper can take a while so you can run the script in test mode to get some immediate satisfaction. In test mode it contains some test zypper output which it parses:

  $ env TEST=1 sh check_zypper
  3 Updates needed:  package-1(required/Needed), package-3(required/Needed), package-4(required/Needed) (1 Optional update)
  $ echo $?
The output text is what Nagios would display on the service-detail page. Nagios will set the service status to "WARNING" since the script status on exit is 1 (meaning updates are availabe).

The script follows:



# Read list of packages that need updating according to zypper.
if [[ $TEST -eq 0 ]]; then
    zypper_lines=($(/usr/bin/sudo /usr/bin/zypper list-updates 2>&1))
    if [[ $stat -ne 0 ]]; then
        echo "Zypper exited with code: $stat"
        exit 1
        "test line 1"
        "test line 2"
        "Main Repository | package-1 | 50-0  | required | Needed"
        "Main Repository | package-2 | 48-0  | optional | Needed"
        "Test Repository | package-3 | 40-0  | required | Needed"
        "Test Repository | package-4 | 40-0  | required | Needed"

# Count the number of optional and non-optional packages.

for ix in ${!zypper_lines[*]}
    if [[ $VERBOSE -ne 0 ]]; then echo $line; fi

    if [[ $in_packages -eq 0 ]]; then
        if [[ $line =~ ^---- ]]; then in_packages=1; fi
        set -- $line
        if [[ $# -eq 5 ]]; then
            trepo=$(echo $1)
            tpackage=$(echo $2)
            tversion=$(echo $3)
            tcategory=$(echo $4)
            tstatus=$(echo $5)
            if [[ "$tcategory" == 'optional' ]]; then
                let noptional_packages++
                let npackages++
                if [[ "$tcategory" == 'security' ]]; then let nsecurity_packages++; fi
# Output summary.
if [[ $npackages -ne 1 ]]; then s1='s'; else s1='' ; fi
if [[ $noptional_packages -ne 1 ]]; then s2='s'; else s2='' ; fi

for ix in ${!package[*]}
    let n++
    if [[ ix -eq $max_packages ]]; then break; fi

if [[ ${#package[*]} -gt $max_packages ]]; then t[$n]="..."; fi

if [[ ${#t[*]} -gt 0 ]]; then
    if [[ $npackages -gt 0 ]]; then
        echo -n "$npackages Update$s1 needed: "
        for ix in ${!t[*]}
            if [[ $first -eq 1 ]]; then
                echo -n ' '
                echo -n ', '
            echo -n "${t[$ix]}"
        if [[ $noptional_packages -gt 0 ]]; then
            echo -n " ($noptional_packages Optional update$s2)"
        echo -n "$noptional_packages Optional update$s2"
    if [[ $nsecurity_packages -gt 0 ]]; then stat=2; fi
    echo "OK, no package updates available"

exit $stat

There are a few things you need to do to integrate the script with Nagios. First setup sudo to allow the Nagios user to run zypper. Use visudo to add this to the sudoers file:

   nagios    ALL=(ALL) NOPASSWD:/usr/bin/zypper
Second, because running zypper takes a while you need to increase the service-run-time in the Nagios configuration file /etc/nagios/nagios.cfg:
And lastly, of course, you need to setup Nagios to run the script:

define command{
        command_name    check-zypper
        command_line    /path/to/check_zypper


define service{
        use                             generic-service
        host_name                       localhost
        service_description             Updates
        is_volatile                     0
        check_period                    24x7
        max_check_attempts              1
        normal_check_interval           600
        retry_check_interval            60
        contact_groups                  admins
        notifications_enabled           0
        notification_options            c
        notification_interval           960
        notification_period             24x7
        check_command                   check-zypper
Among other things, this tells Nagios to run check_zypper every 10 hours and if it fails, to retry in an hour.

p.s. Yeah, the title is pretty "cheap humor", but then again I'm not the one who decided to call my package manager zypper.


Mitch Frazier is an Associate Editor for Linux Journal.


Comment viewing options

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

Complete nagios-plugins-zypper package already available

Lars Vogdt's picture


Just want to point you to - the "server:monitoring" repository of the openSUSE Build Service always contains the latest version.

This plugin allows you a bit more configuration than your bash script and runs out of the box on all supported openSUSE distributions.

You can set the warning level via "patchlevel". Default is: security-patch: Critical; recommended-patch: Warning

It also checks for package updates from buildservice repositories and catches some possible traps (refresh needed, no online connection, ...).

The package integrates completely in a nagios installation - see the description on the page listed above.

With kind regards,

reduced timeout

hiney's picture

to reduce the need for the increased timeout, use cron on the target machine(s) to output the 'zypper lu' to a file. this script can then use that file instead.

can you supply some usage instructions ?
eg : how does TEST and VERBOSE get specified to make 'TEST=${TEST:-0}' and 'VERBOSE=${VERBOSE:-0}' work ?

Test and Verbose

Mitch Frazier's picture

Those are meant for testing outside of nagios, rather than clutter it all up with command line argument processing those are just set from the environment. So, for example you could test via:

  env TEST=1 VERBOSE=1 sh check_zypper

Mitch Frazier is an Associate Editor for Linux Journal.

One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix