Update df.py

[Man-in-Black]

General information

This change affects the Checkmk Linux agent disk space check (df), specifically the order in which df_blocks entries are processed. The df check is used to monitor filesystem usage on Linux/Unix systems and relies on the order of mount point rules to determine which paths are included or excluded from monitoring.

Bug reports

Please include:

• Your operating system name and version
  • Ubuntu 24.04 LTS
• Any details about your local setup that might be helpful in troubleshooting
  • Checkmk Ultimate (previous Cloud) Edition
  • Linux agent deployed on a Docker host with multiple active containers
  • /var/lib/docker contains overlay2 filesystems, volumes and container layers
  • df_blocks ruleset was configured with a custom inclusion rule for /var/lib/docker, but the rule had no effect due to processing order
• Detailed steps to reproduce the bug
  1. Set up a Linux host running Docker with data stored under /var/lib/docker
  2. In Checkmk, navigate to Setup → Service discovery rules → Discovery of filesystem mountpoints
  3. Add an explicit inclusion rule for /var/lib/docker (or a sub-path like /var/lib/docker/overlay2)
  4. Run a service discovery on the host
  5. Observe that /var/lib/docker mount points are not discovered, despite the inclusion rule
  6. After applying the patch (reordering df_blocks), repeat the discovery — the mount points now appear correctly

Proposed changes

What is the expected behavior?

By reordering the df_blocks entries, it should be possible to define rules that explicitly allow monitoring of /var/lib/docker and its subpaths (e.g. overlay mounts, volumes), even though these are typically excluded by default or overridden by broader exclusion rules.

What is the observed behavior?

Previously, the order of entries in df_blocks caused broad exclusion rules (e.g. for virtual or overlay filesystems used by Docker) to take precedence over more specific allow rules for /var/lib/docker. As a result, Docker-related mount points were silently skipped and could not be monitored even when explicitly configured.

In what way does your patch change the current behavior?

The patch changes the order of entries in df_blocks so that more specific inclusion rules are evaluated before broader exclusion rules. This follows a "most specific rule wins" principle and aligns with the expected behavior when an administrator explicitly wants to monitor /var/lib/docker.

Is this a new problem?

This issue becomes relevant in environments where Docker is heavily used and disk space monitoring of /var/lib/docker is required — for example, to detect runaway image/container storage consumption. The need arose from operational requirements in Docker-based infrastructure where unmonitored storage growth caused incidents.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Man-in-Black]

I have read the CLA Document and I hereby sign the CLA or my organization already has a signed CLA.

[Man-in-Black]

recheck