Repository navigation
fix(collector): preserve jmb39x-q device type and accept usable SMART JSON #663
Description
Summary
Scrutiny cannot reliably monitor QNAP TR-004 disks in Individual mode when smartmontools uses the jmb39x-q,N backend.
Source
Upstream discussion: AnalogJ#1028
Problem
Two collector behaviors prevent usable SMART data:
- A configured device type such as
jmb39x-q,0is split into separate arguments instead of being passed as one--device jmb39x-q,0value. - The collector rejects otherwise complete SMART JSON when smartctl returns
exit_status = 4for the non-fatal warningRead Device Statistics page 0x00 failed.
Expected behavior
- Preserve
jmb39x-q,Nas one smartctl device-type argument for information and SMART collection commands. - Parse and store valid SMART data when the JSON contains usable identity and metrics despite a non-zero warning status.
- Continue rejecting genuinely unusable or fatal smartctl output.
Acceptance criteria
- Add regression coverage for comma-containing device types such as
jmb39x-q,0. - Add regression coverage for valid SMART JSON with non-zero warning exit status.
- Verify QNAP TR-004 collection produces device identity and SMART metrics instead of
No Data. - Document any required QNAP collector configuration.
Activity
Starosdev commentedon Jul 28, 2026
Fixed in #677.
Both reported behaviors were real, and the second one turned out to be the more damaging of the two.
Device type splitting. The argument construction was never at fault. All three
--devicecall sites already appended the type as a single element, and the shell layer usesexec.CommandContextwith no re-tokenization. The split happened earlier, at config parse time: viper installs a decode hook that splits a scalar string on commas when the destination is a slice, sotype: 'jmb39x-q,0'decoded to the two bogus typesjmb39x-qand0. A comma is part of the smartctl device-type grammar, not a separator, so that hook is now overridden for thedeviceskey. Both the scalar form and the list form now preserve the type intact.Non-zero warning exit status.
SmartCtlInfomasked the exit code with0xBF, but the tolerant branch logged "Continuing." and then fell straight into a pre-existingreturn err. It was dead code, so no non-zero smartctl exit had ever survived detection. Detection now uses the same rule the collection path and the server-side upload validation already applied: only exit bits0x01and0x02mean the payload cannot be trusted, because every other bit describes a condition of the disk rather than of the output. Empty or identity-less output is still rejected.Worth noting for anyone who worked around the first bug with the list form
type: ['jmb39x-q,0']: you were still affected. Without the second fix the drive registered with no serial and therefore no WWN, and since every metrics query filters on thedevice_wwntag, that empty WWN is what actually producedNo Data.Acceptance criteria:
jmb39x-q,0- config parsing in scalar and list form, plus--deviceargv assertions on all three smartctl call sites.docs/TROUBLESHOOTING_DEVICE_COLLECTOR.md, plus an example inexample.collector.yaml.Two things that would benefit from a hand on the actual hardware:
COLLECTOR_DEBUG=trueand confirming the logged command line shows--device jmb39x-q,0as one argument, and that the disks report model/serial/capacity, would close it out.--info --jsonresponse rather than captured from a realjmb39x-qdevice. Sanitized real output fromsmartctl --info --json -d jmb39x-q,0 /dev/sdXwould make the regression test stronger. Happy to swap it in.One upgrade note: a drive affected by either bug was registered through the metadata-less identity fallback. Once its model, serial and WWN can be read it hashes to a new device id and shows up as a new device, leaving the old
No Dataentry behind. Delete the stale entry; its history is empty and cannot be merged usefully.fix(collector): preserve jmb39x-q device type and accept usable SMART…
chore(release): 2.0.0-beta.1