Summary
Add Unraid /proc/mdstat parsing support to the MDADM collector so Unraid-backed arrays can be detected and surfaced in Scrutiny.
Problem
Issue #530 is now validated on a standard Linux MDADM host, but Zeus still cannot populate MDADM arrays because Unraid does not expose the standard Linux mdadm /proc/mdstat format that the current detector expects.
Current detector expectation:
- lines like
md0 : active raid1 ...
Observed live Zeus /host/proc/mdstat shape:
- key/value lines like
mdState=STARTED
diskNumber.0=...
rdevName.0=sdd
diskName.1=md1p1
So the current collector deployment on Zeus is healthy, but the detector logs:
No MDADM arrays found in /proc/mdstat
That means Unraid remains unsupported for actual MDADM ingestion even when the container is wired correctly.
Evidence
Live Zeus testing on develop revision eb050029d65ff47c8eb24ecd09618f72471e13b4 showed:
GET /api/health healthy
- authenticated
GET /api/mdadm/summary returned {"data":[],"success":true}
scrutiny-collector-mdadm run --debug logged:
Starting MDADM array collection
No MDADM arrays found in /proc/mdstat
No MDADM arrays found
/host/proc/mdstat was mounted correctly, but contained Unraid key/value metadata instead of standard Linux mdX : active ... lines.
Separate validation on Helios confirmed that #530 itself is fixed on a standard Linux MDADM host:
- temporary loopback RAID1 array detected correctly
- repeated collector runs registered and updated the same array successfully
- no
SQL logic error: row value misused (1) on re-registration
So this follow-up is about Unraid detection support, not the #530 registration bug.
Proposed Scope
- extend MDADM detection to recognize Unraid
/proc/mdstat format
- map Unraid array metadata into the existing
MDADMArray and MDADMMetrics structures where possible
- preserve current standard Linux MDADM parsing behavior
- add tests for both standard Linux and Unraid
/proc/mdstat parsing
- verify on Zeus testing after implementation
Acceptance Criteria
- collector detects Unraid-backed arrays from Zeus-style
/proc/mdstat
- Zeus
scrutiny-dev can populate authenticated GET /api/mdadm/summary with real array entries
- standard Linux MDADM detection still works
- tests cover both parsing modes
Notes
This should stay scoped to detection/parsing support for Unraid's mdstat format. It should not reopen the backend registration work already addressed in #530.
Summary
Add Unraid
/proc/mdstatparsing support to the MDADM collector so Unraid-backed arrays can be detected and surfaced in Scrutiny.Problem
Issue
#530is now validated on a standard Linux MDADM host, but Zeus still cannot populate MDADM arrays because Unraid does not expose the standard Linuxmdadm/proc/mdstatformat that the current detector expects.Current detector expectation:
md0 : active raid1 ...Observed live Zeus
/host/proc/mdstatshape:mdState=STARTEDdiskNumber.0=...rdevName.0=sdddiskName.1=md1p1So the current collector deployment on Zeus is healthy, but the detector logs:
No MDADM arrays found in /proc/mdstatThat means Unraid remains unsupported for actual MDADM ingestion even when the container is wired correctly.
Evidence
Live Zeus testing on
developrevisioneb050029d65ff47c8eb24ecd09618f72471e13b4showed:GET /api/healthhealthyGET /api/mdadm/summaryreturned{"data":[],"success":true}scrutiny-collector-mdadm run --debuglogged:Starting MDADM array collectionNo MDADM arrays found in /proc/mdstatNo MDADM arrays found/host/proc/mdstatwas mounted correctly, but contained Unraid key/value metadata instead of standard LinuxmdX : active ...lines.Separate validation on Helios confirmed that
#530itself is fixed on a standard Linux MDADM host:SQL logic error: row value misused (1)on re-registrationSo this follow-up is about Unraid detection support, not the
#530registration bug.Proposed Scope
/proc/mdstatformatMDADMArrayandMDADMMetricsstructures where possible/proc/mdstatparsingAcceptance Criteria
/proc/mdstatscrutiny-devcan populate authenticatedGET /api/mdadm/summarywith real array entriesNotes
This should stay scoped to detection/parsing support for Unraid's
mdstatformat. It should not reopen the backend registration work already addressed in#530.