Linux RAID Degradation Alerts With mdadm Monitor

This article explains the purpose and functionality of the mdadm --monitor command in the Linux operating system. It details how the monitor flag operates as an active background watchdog to detect software RAID degradation, how it generates automated alerts to notify system administrators, and why continuous array monitoring is vital for preventing catastrophic data loss following a storage drive failure.

In Linux software RAID management, the --monitor flag (also accessible via -F or --follow) instructs the mdadm utility to run continuously as a monitoring daemon. Rather than performing a one-time operation, this mode tracks the real-time health and status of multiple device (/dev/md*) arrays by polling the system and listening to internal kernel events.

The primary purpose of running mdadm in monitor mode is to detect when a redundant RAID array (such as RAID 1, 5, 6, or 10) enters a degraded state. Redundant RAID levels tolerate one or more drive failures without taking the storage offline or corrupting data. Because the operating system continues running uninterrupted when a disk fails, an administrator might remain completely unaware of the failure. If a secondary drive fails while the array is already degraded, complete data loss can occur. The --monitor flag mitigates this risk by identifying disk failure events immediately as they happen.

When active, mdadm --monitor listens for specific state changes, including:

• Fail and DegradedArray: Triggered when an active drive in the array fails or an array drops below its designated redundancy level.
• FailSpare: Triggered when an allocated spare drive experiences a failure.
• SparesMissing: Warns when an array lacks the configured number of spare devices.
• RebuildStarted and RebuildFinished: Reports when data synchronization begins and completes on a replacement drive.

To ensure administrators can act swiftly, the monitor mode provides built-in alerting mechanisms:

1. Email Alerts: Using the --mail parameter (or the MAILADDR directive in /etc/mdadm/mdadm.conf), the monitor automatically sends an email containing details of the affected array, the failed device, and the current state directly to a specified inbox.
2. Custom Script Execution: Using the --program parameter (or the PROGRAM directive), mdadm can execute a custom shell script whenever an event is triggered. This allows organizations to pipe alerts into third-party incident management platforms, Slack channels, or enterprise monitoring systems such as Zabbix or Prometheus Alertmanager.
3. System Logging: Critical state changes are recorded to the system logger (syslog or systemd-journald), preserving an audit trail of the hardware event.

In modern Linux distributions, this monitor functionality is typically managed by a background systemd service, such as mdmonitor.service. When executed with the syntax mdadm --monitor --scan --daemonise, the process queries /etc/mdadm/mdadm.conf, detaches into the background, and ensures persistent surveillance over all active storage pools.