Skip to content
Search Rocky Linux

    Browse this documentation

    Rocky 9: SMART detection and making smartd alerts real

    Executed in a Rocky 9.8 environment (privileged container, host kernel 5.14.0-687.54.1.el9_8) and on the same host: lsblk -d, smartctl --scan, smartctl -i /dev/vda, -d sat, -d nvme, systemctl is-active smartd, and the default smartd.conf. Log: plans/content-expansion/evidence/logs/rocky-disk-health.log.

    The virtual disk here exposes no SMART, so the “when it works” part follows the default configuration; no output from a real SATA/NVMe disk was produced here.

    1. lsblk -d -o NAME,TYPE to see what kind of disk it is;
    2. smartctl --scan to see whether it enumerates;
    3. smartctl -i /dev/<disk> for model and SMART support;
    4. if it cannot be read, move monitoring to the cloud platform, array controller or host.
    Terminal window
    sudo smartctl --scan
    sudo smartctl -i /dev/vda
    (no output)
    /dev/vda: Unable to detect device type
    Please specify device type with the -d option.

    Explicit types fail too:

    Read Device Identity failed: Inappropriate ioctl for device
    Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for device

    The virtio disk does not pass SMART through, so no configuration on the guest can read it.

    What the default smartd configuration looks like

    Section titled “What the default smartd configuration looks like”
    Terminal window
    grep -vE "^#|^$" /etc/smartmontools/smartd.conf | head -2
    systemctl is-active smartd
    DEVICESCAN -H -m root -M exec /usr/libexec/smartmontools/smartdnotify -n standby,10,q
    inactive

    DEVICESCAN scans every supported disk and mails root on a failed health check. With no scannable devices it raises nothing — exactly the “we think we have monitoring” trap in virtual environments.

    Terminal window
    dmesg -T | grep -iE "i/o error|medium error|link reset" | tail -5
    sudo mdadm --detail /dev/md0 2>/dev/null | grep -E "State|Faulty"
    • Kernel log: I/O and medium errors are the most direct hardware-layer symptom;
    • Software RAID: State turns degraded and Faulty Devices names the disk;
    • Hardware RAID: vendor CLI (storcli/perccli/ssacli);
    • Cloud disks: console health checks and events.
    • Treating -d sat as a universal flag: a wrong type only yields ioctl errors;
    • Configuring smartd without devices: it looks like monitoring but reports nothing;
    • Watching SMART only: behind a RAID controller SMART is usually swallowed.

    Practice: define a monitoring plan for one host

    Section titled “Practice: define a monitoring plan for one host”
    Terminal window
    sudo dnf install -y smartmontools mdadm
    sudo smartctl --scan
    sudo smartctl -i /dev/<disk> || echo "SMART unavailable"
    dmesg -T | grep -icE "i/o error|medium error"
    sudo mdadm --detail /dev/md0 2>/dev/null | grep State

    Checks:

    1. You can state whether this host can read SMART
    2. If not, you can name where monitoring belongs
    3. You can list at least two substitute signals

    常见问题

    Why can a virtio disk not expose SMART?

    SMART commands use ATA/NVMe-specific channels that virtual disks usually do not pass through; only the cloud platform or host sees physical disk state.

    Is the default smartd configuration enough?

    On physical hosts DEVICESCAN with -m root is a reasonable start, provided mail delivery and recipients are configured; do not rely on it in virtual environments.

    How do I monitor disks behind a RAID controller?

    Use the vendor CLI for array and physical disk state and enable controller event alerts; SMART is often intercepted by the controller and smartctl cannot see it.