New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Standby-Support][BUG] Disks in standby mode are not correctly processed/detected - Scrutiny will create a duplicate disk with empty data #157
Comments
adding the ability to delete disks is definitely on my backlog. I'll be closing this as a dupe of #69 |
oh actually this looks like an error related to invalid disks being detected. |
Can you include your collector logs? |
@AnalogJ do you mean this? https://gist.github.com/garret/aef16aa7fafd9de73aee0eb57ec55315 |
I too have this exact issue, also on a Raspberry Pi 4 with the linuxserver docker image. In my case, @garret does your disk also go into sleep mode? |
@ngkengwooi I have exactly the same situation as you describe in your message. |
As a workaround while waiting for a fix, I added a cron job to wake the disk up ( |
This also happened to me. The power cable on the hard drive came loose somehow while the system was powered on. While the disk was unplugged a check was run which caused the 'phantom disk' to appear. |
interesting. @ngkengwooi @garret can you possibly get me the |
@AnalogJ I don't know if I have done things right but this is my
I do not really know exactly what command should I give for In the meanwhile, just to recap again, when I open the scrutiny webinterface, this is what I get: |
Thanks @garret Can you run the following commands, and attach the output files.
|
I am using portainer terminal to give such commands and it seems that the result is quite long and thus some of it might be cut. You tell me if these info are enough and need to find a way to give them through proper terminal:
|
@AnalogJ, here's mine, same issue with
|
@AnalogJ Yes, I run the commands after a long time of idle when I haven't accessed anything on the disk for many hours. The way I see that the hdd goes out of sleep is that when trying to access via ssh to its content I get a delay of like 20 seconds to "ls" on it, so the hdd to starts spinning up. I can also hear it. |
ahh ok. I just took a closer look at that non-zero exit code of
In general, scrutiny shouldn't be forwarding empty, invalid data from the collector to the webapp, but we ignore non-zero exit codes because I'll need to come up with a generic process to handle disks in standby mode or that haven't been "seen" in a while -- maybe just a new notification rule. Atleast I know what to look for now. Thanks for all the data everyone! 👍 |
Just to add to the logs and provide some suggestions. This is a sleeping external USB hard drive. The hard drive appeared to be too slow to respond to smartctl in its spin up Suggestion 1: Include a quick read from the drive before running smartctl Suggestion 2: Include a probe of the drives before running smartctl Suggestion 3: Work around Recommendation Additional Enhancement Logs showing one sleeping drive (sdc)
|
Having the same problem on an Unraid server. When the SAS drives are spun down and the smart read is triggered, it throws read errors in the logs. If it goes on long enough the phantom drives start appearing leading to disks being deactivated. No damage done as long as I catch it before a 3rd disk is deactivated, just an 18hr data rebuild. If disk spindown is disabled everything works fine. Since unraid logs are dynamic, I don't currently have any to upload. I'll see if I can get it to do it again and capture a diagnostic image after the current rebuild finishes if you need them. |
Hey @edfield are you saying that running Smartctl/Scrutiny is causing corruption/errors in your RAID causing a re-build? |
Not corruption, but after a number of failed reads, unraid will deactivate the drive. To get the drive back in the array takes a data rebuild. I run 2 parity drives so 2 drives can be deactivated with no loss, a third would be real bad. I have 14 data drives so quite a few are spun down most of the time. All drives are SAS enterprise drives with 2 adaptec SAS controllers. |
Describe the bug
I installed scrutiny through the linuxserver docker container on a raspberry pi 4 to which I have attached two disks by USB connection. When running for the first time
scrutiny scrutiny-collector-metrics run
command, my two hard disk are recognized. One is a hdd while another is a ssd. Thus, I have two entries on scrutiny (that is expected behaviour). However, I have noticed that after some time (like around a day) a new "empty" entry appears. I have marked it in red in the below screenshot. Do you know how to get rid of that fake entry?Expected behavior
Scrutiny should only list my two disks. It does it but also shows another entry of a "phantom" disk.
Screenshots
The text was updated successfully, but these errors were encountered: