Falsi allarmi monitoring: mdadm, smartd e monit — diagnosi e risoluzione

Data: 16/09/2026 · Host: nas64 (NAS-MAIN), nas64sas (NAS-BACKUP) · Stato: risolto

Contesto

Tre alert di monitoring apparentemente gravi ma senza causa reale, verificati e bonificati in un'unica sessione di manutenzione:

1. mail giornaliera mdadm con DeviceDisappeared / NewArray su md127;
2. mail smartd quotidiana "Failed SMART usage Attribute: 194 Temperature_Celsius" sul disco SSD di sistema;
3. mail monit "filesystem Does not exist" arrivata dopo uno spegnimento manuale.

Nessuno dei tre era un guasto reale: si trattava di falsi positivi noti o di race-condition nella sequenza di spegnimento.

1. mdadm — DeviceDisappeared / NewArray quotidiano su md127

Sintomo

Mail giornaliera (orario variabile, via anacron):

/etc/cron.daily/openmediavault-mdadm:
mdadm: DeviceDisappeared event detected on md device /dev/md/md127
mdadm: NewArray event detected on md device /dev/md127

Indagine

• md127 (RAID1, 2× WD40EFPX) in stato clean [UU], contatore Events stabile, SMART dei membri PASSED;
• l'evento si riproduce ad ogni esecuzione di mdadm --monitor --scan --oneshot (riproduzione 3/3 run a 2 s di distanza) → nessun evento reale;
• nas64 senza reboot dal 13/09 → non è un artefatto di boot;
• la causa della mail è /etc/cron.daily/openmediavault-mdadm, che esegue mdadm --monitor --scan --oneshot e il cui stdout viene inoltrato da cron (run-parts/anacron).

Causa

Bug noto di mdadm 4.x: con ARRAY /dev/md127 in /etc/mdadm/mdadm.conf, il monitor vede lo stesso array due volte: /dev/md/md127 (percorso "container" del devtmpfs) e /dev/md127. Ogni run lo segnala prima come sparito (DeviceDisappeared) e poi come nuovo (NewArray).

Risoluzione applicata

In /etc/cron.daily/openmediavault-mdadm l'output viene dirottato a syslog invece che a stdout:

$MDADM --monitor --scan --oneshot 2>&1 | logger -t omv-mdadm-cron

• Backup: /etc/cron.daily/openmediavault-mdadm.bak-20260916-090139
• Gli eventi (fittizi o reali) restano tracciabili: journalctl -t omv-mdadm-cron

Nota: OMV può rigenerare lo script in caso di aggiornamenti → se la mail ricompare, riapplicare la modifica.

2. smartd — Failed SMART usage Attribute: 194 Temperature_Celsius (SSD CT120BX500 = /dev/sdb)

Sintomo

Mail smartd dal 01/09/2026, poi ripetuta ogni 24h:

Device: /dev/disk/by-id/ata-CT120BX500SSD1_2036E40FF2AF [SAT],
Failed SMART usage Attribute: 194 Temperature_Celsius.

Indagine

• smartctl -H: overall-health PASSED;
• temperatura attuale 40–42 °C, storico min/max 25/67 °C, Power-On 5994 h;
• attributo 194: VALUE 60 > THRESH 50, ma WHEN_FAILED = In_the_past.

Causa

Il flag In_the_past dell'attributo 194 resta impresso sul drive (comportamento noto Crucial BX500): una volta che la temperatura ha superato il threshold in passato, l'attributo rimane segnalato come "fallito" anche da freddo. smartd continua quindi a notificare ogni 24 h, senza reale problema.

Risoluzione applicata

In /etc/smartd.conf, per quel device: aggiunto -I 194 (ignora l'attributo 194 nel check "failed"):

/dev/disk/by-id/ata-CT120BX500SSD1_2036E40FF2AF \
  -m hermesgirl@busce.it -M exec /usr/share/smartmontools/smartd-runner -I 194

• Le soglie -W 5,55,60 restano attive: se la temperatura sale davvero a 55/60 °C (o cambia di >5 °C), l'alert scatta comunque;
• verifica post-fix: riavvio pulito, 0 messaggi fail/marginal, 3 device monitorati;
• backup: /etc/smartd.conf.bak-20260916-090139, /etc/smartd.conf.bak-cleanup-20260916-093xxx.

Raccomandazioni e pulizia correlata

• Il picco storico a 67 °C (vicino al limite di 70 °C del BX500) segnala poco ricambio d'aria nel periodo estivo → da tenere d'occhio;
• è stata rimossa anche l'entry stale del WD30EFRX (WD-WCC4N5EUULYX, ex disco USB usato per backup, non più collegato): la GUI OMV non la mostra perché elenca solo i dischi presenti, quindi la rimozione è stata fatta da CLI:
  • omv-confdbadm delete conf.service.smartmontools.device --uuid f8ae8322-2ad1-4400-8100-a7e4cead153d
  • smartd.conf rigenerato con i soli 3 dischi presenti.

Nota: OMV rigenera /etc/smartd.conf al save dei settings SMART dalla GUI → dopo un salvataggio, riapplicare -I 194.

3. monit — "filesystem ... Does not exist" dopo uno spegnimento manuale

Sintomo

Mail monit (15/09 alle 20:47:41) da nas64sas:

Service: filesystem_srv_dev-disk-by-uuid-c39db90f-...
Event:   Does not exist

Analisi

Non era sparito un disco: era in corso uno spegnimento manuale della macchina:

• 20:47:40 systemd ferma i timer e smonta md5 (XFS unmount pulito);
• 20:47:41 monit (ancora attivo durante lo shutdown) controlla il filesystem → non più in /proc/self/mounts → "Does not exist";
• 20:47:42 l'invio mail fallisce (SMTP già spento: "Connection reset by peer") → evento accodato;
• al boot successivo (run notturno delle 03:00) monit consegna la coda → la mail arriva "in nottata".

Oggi: md5 [UUU] (3/3 dischi), XFS montato, 3 TiB liberi (59% usati). Nessuna azione necessaria: per evitare il falso positivo basta spegnere dall'interfaccia OMV (ferma monit prima dello smontaggio) oppure eseguire lo spegnimento quando il monitoring è già fermo.

4. Riepilogo verifiche utili

# stato array (nas64)
cat /proc/mdstat
mdadm --detail /dev/md127 | grep -E "State|Events"

# eventi mdadm (dopo il fix: in syslog, non in mail)
journalctl -t omv-mdadm-cron -n 20

# smartd
journalctl -t smartd -n 20 | grep -E "Monitoring|failed"
smartctl -a /dev/disk/by-id/ata-CT120BX500SSD1_2036E40FF2AF | grep -E "194|overall"

# config OMV smart (dispositivi monitorati)
omv-confdbadm read conf.service.smartmontools.device

Note operative

• /etc/smartd.conf è generato da OMV → "Do not edit, changes will get lost": i fix applicati vanno ripristinati dopo qualsiasi save GUI dei settings SMART;
• /etc/cron.daily/openmediavault-mdadm può essere rigenerato dagli update OMV;
• file modificati (tutti con backup con timestamp): /etc/smartd.conf, /etc/cron.daily/openmediavault-mdadm, /etc/openmediavault/config.xml (rimozione device stale).