Closed ltctceplrm closed 2 years ago
spupuz
commented
3 years ago I after changing some failed disk I have the same error, would be better to analyze disks based on dev-by-and not /dev/sdX. Additionally, would be better been able to remove removed device or at lease hide them
AnalogJ
commented
3 years ago Scrutiny uses the disk WWN/UUID as the primary identifier, the device name (/dev/dba) is only used for visual purposes.
I definitely want to figure out where these ghost/empty device entries are coming from (a couple of other people have submitted similar issues). Would you be willing to give me full logs from your collector runs
also, can you run the following commands:
smartctl --scan -j
smartctl --info -j -d sat /dev/sdc
smartctl -x -j /dev/sdcThanks!
ltctceplrm
commented
3 years ago Thank you for checking this out, here's what I get when I run the commands:
smartctl --scan -j
{ "json_format_version": [ 1, 0 ], "smartctl": { "version": [ 7, 2 ], "svn_revision": "5155", "platform_info": "x86_64-linux-5.10.0-8-amd64", "build_info": "(local build)", "argv": [ "smartctl", "--scan", "-j" ], "exit_status": 0 }, "devices": [ { "name": "/dev/sda", "info_name": "/dev/sda", "type": "scsi", "protocol": "SCSI" }, { "name": "/dev/sdb", "info_name": "/dev/sdb [SAT]", "type": "sat", "protocol": "ATA" }, { "name": "/dev/sdg", "info_name": "/dev/sdg [SAT]", "type": "sat", "protocol": "ATA" } ] }
smartctl --info -j -d sat /dev/sdc
{ "json_format_version": [ 1, 0 ], "smartctl": { "version": [ 7, 2 ], "svn_revision": "5155", "platform_info": "x86_64-linux-5.10.0-8-amd64", "build_info": "(local build)", "argv": [ "smartctl", "--info", "-j", "-d", "sat", "/dev/sdc" ], "exit_status": 2 }, "device": { "name": "/dev/sdc", "info_name": "/dev/sdc [SAT]", "type": "sat", "protocol": "ATA" } }
smartctl -x -j /dev/sdc
{ "json_format_version": [ 1, 0 ], "smartctl": { "version": [ 7, 2 ], "svn_revision": "5155", "platform_info": "x86_64-linux-5.10.0-8-amd64", "build_info": "(local build)", "argv": [ "smartctl", "-x", "-j", "/dev/sdc" ], "messages": [ { "string": "/dev/sdc: Unknown USB bridge [0x058f:0x6362 (0x100)]", "severity": "error" } ], "exit_status": 1 } }
For the collector logs do I just need to add this to docker compose?
DEBUG=true
COLLECTOR_LOG_FILE=/tmp/collector.logThis should be fixed in the v0.4.x releases. We check for empty data (when smartctl silently fails) and we correctly ignore "ghost" devices.
Also the UI now allows you to identify your devices with different titles:
fixed in v0.4.7 🎉
Describe the bug I've got one specific hard drive (/dev/sdc) that has some difficulty being picked up by smartmontools but gets noticed correctly right away by scrutiny, I've got that hard drive another in my docker compose file but whenever I restart the container /dev/sdc is duplicates, one with SMART data and one without. I can fix this by removing the empty /dev/sdc entry in the database and starting scrutiny up but next reboot it's again duplicated.
Expected behavior Since /dev/sdc is already in the database it shouldn't duplicate it after restarting the container.
Screenshots Screenshot of the webui Screenshot of how the database looks
Log Files Since this is the opposite of a missing device and the SMART data works fine I'm not sure if you want me to run it in collector mode or not? But looking through docker stats I see the following mentions of /dev/sdc with the creation date for the duplicated entry:
Please let me know if I let any identifying info in the logs, it's sometimes hard to read.
My docker compose entry is: