[Bug] dashdot prevents one hdd from standby

[ristein]

Description of the bug

As long as dashdot docker container is running, one of my HDDs is woken every ~30s. If I set it to sleep/standby it would be active/idle again about 20s later. I'm using this command to start dashdot:

docker run -it --name dashdot -p 12137:3001 --privileged --restart=unless-stopped --env DASHDOT_SHOW_HOST="true" --env DASHDOT_SHOW_DASH_VERSION="bottom_right" --env DASHDOT_ALWAYS_SHOW_PERCENTAGES="true" --env DASHDOT_PAGE_TITLE="dash.domain.com" --env DASHDOT_NETWORK_LABEL_LIST="type,speed_up,speed_down,interface_speed,public_ip" -v /:/mnt/host:ro mauricenino/dashdot

I have two similar HDDs in a raid, but only sdc is affected, difference is the additional partition there: sudo blkid | grep -E 'sda|sdc' /dev/sda: UUID="50bcf8e3-684f-6aa2-b325-bb179aecbe3d" UUID_SUB="168752fb-a767-8fa3-31d3-b51b1d7963bb" LABEL="richihomecl:0" TYPE="linux_raid_member" /dev/sdc1: UUID="50bcf8e3-684f-6aa2-b325-bb179aecbe3d" UUID_SUB="777aced7-3e40-f978-54cf-badee5b17989" LABEL="richihomecl:0" TYPE="linux_raid_member" PARTUUID="6360d8c2-01"

How to reproduce

No response

Relevant log output

No response

Info output of dashdot cli

~$ docker exec dashdot yarn cli info
yarn run v1.22.19
$ node dist/apps/cli/main.js info
node:internal/modules/cjs/loader:1080
  throw err;
  ^

Error: Cannot find module 'systeminformation'
Require stack:
- /app/dist/apps/cli/apps/cli/src/main.js
- /app/dist/apps/cli/main.js
    at Module._resolveFilename (node:internal/modules/cjs/loader:1077:15)
    at Module._resolveFilename (/app/dist/apps/cli/main.js:32:36)
    at Module._load (node:internal/modules/cjs/loader:922:27)
    at Module.require (node:internal/modules/cjs/loader:1143:19)
    at require (node:internal/modules/cjs/helpers:121:18)
    at Object.<anonymous> (/app/dist/apps/cli/apps/cli/src/main.js:26:18)
    at Module._compile (node:internal/modules/cjs/loader:1256:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1310:10)
    at Module.load (node:internal/modules/cjs/loader:1119:32)
    at Module._load (node:internal/modules/cjs/loader:960:12) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/app/dist/apps/cli/apps/cli/src/main.js',
    '/app/dist/apps/cli/main.js'
  ]
}

Node.js v18.17.1
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

What browsers are you seeing the problem on?

No response

Where is your instance running?

Desktop PC (Linux)

Additional context

No response

[ayykamp]

You can probably set DASHDOT_STORAGE_POLL_INTERVAL to a higher value, default is 60s

[ristein]

problem is, this drive stays in standby 90% of the time. dashdot should not wake it, as scrutiny and homepage also manage to do

[MauriceNino]

Hi there! There are two solutions:

1. As @ayykamp suggested, up the poll interval for now. If you don't have very variable data, once every few hours should be ok as well
2. Ask @sebhildebrandt about it on his repository: https://github.com/sebhildebrandt/systeminformation. This is the library I use for gathering basically all the data, so maybe you can troubleshoot together what's the issue and if we can maybe add a flag that avoids waking up HDDs.

[sebhildebrandt]

Hi, it me (creator of the underlying systeminformation library). I am not sure if this is really a thing that the underlying lib should support. It would make sense to first check, if some sort of settings in your app should prevent waking up HDDs and dependendent on that setting and the status of the HDD, you call the lib ... what do you think?

[MauriceNino]

@sebhildebrandt Yeah, but that would basically disable storage information gathering while the HDD is asleep, I think.

@ristein Do the other apps still work, while the HDD is asleep?

[ristein]

at least they show correct values. I don't know if they stop querying while HDD is asleep and remember that value until next time awake or if they manage to get free space while asleep

[MauriceNino]

@ristein How do you read if an HDD is asleep? Is there some kind of command?

[ristein]

I use this command: watch sudo hdparm -C /dev/sd[a,b,c] from man hdparm:

   -C     Check the current IDE power mode status, which will always be one of unknown (drive does
          not  support  this  command),  active/idle  (normal operation), standby (low power mode,
          drive has spun down), or sleeping (lowest power mode, drive is  completely  shut  down).
          The -S, -y, -Y, and -Z options can be used to manipulate the IDE power modes.
   -y     Force an IDE drive to immediately enter the low power consumption standby mode,  usually
          causing  it to spin down.  The current power mode status can be checked using the -C op‐
          tion.

After using -y the drive would first wake up once any progress accesses a file on it.

[Deses]

Hi! Chiming in to say that Dash. is preventing all my Unraid array from ever sleeping for me too. As soon as I start the container all my disk spin up. That's quite annoying, and setting up a poll rate is not the best approach either.

As you have discussed already, Dash. should keep watch of the drives and update the values when they happen to be awake, and do nothing if they are asleep. At most I'd allow Dash. to wake up the drives on container startup, and nothing else.

[MauriceNino]

@ristein Can you please try executing this command inside the docker container to see if that information is available there as well?

In case it is, I would implement it to just use the specified poll interval and then first check if the drive is awake.

[ristein]

docker exec -it dashdot hdparm -C /dev/sd[a,b,c] OCI runtime exec failed: exec failed: unable to start container process: exec: "hdparm": executable file not found in $PATH: unknown

hdparm does not seem to be installed in the container

[MauriceNino]

@ristein Can you try to install it manually and then try again?

docker exec -it dashdot /bin/sh

# apk add hdparm
# hdparm -C /dev/sd[a,b,c]

[ristein]

this is working:

$ docker exec -it dashdot /bin/sh
/app # apk add hdparm
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/x86_64/APKINDEX.tar.gz
(1/1) Installing hdparm (9.65-r2)
Executing busybox-1.36.1-r2.trigger
OK: 60 MiB in 70 packages
/app # hdparm -C /dev/sd[a,b,c]

/dev/sda:
 drive state is:  standby

/dev/sdb:
 drive state is:  idle

/dev/sdc:
 drive state is:  active/idle

[MauriceNino]

@sebhildebrandt I just looked into the code and if I am not mistaken, I think there is no option to exclusively check a single disk. The only option I found is to pass a device name to fsSize(device), but it looks like the code still checks all the drives and filters after the fact.

Is this correct? And in case it is, would it be possible to only check the device that is provided as an argument?

[MauriceNino]

@ristein Can you please confirm which command wakes up your HDDs when called from inside the container? Please execute them one after while the HDD is asleep each time, so we can figure out exactly which ones wake it up.

export LC_ALL=C; df -lkPTx squashfs; unset LC_ALL

cat /proc/mounts 2>/dev/null

df -lkPT

lsblk -bPo NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,UUID,ROTA,RO,RM,TRAN,SERIAL,LABEL,MODEL,OWNER 2>/dev/null

Check the above output for a block with a type matching raid... and paste the name of that block in the command below:

mdadm --export --detail /dev/{name}

[ristein]

$ docker exec dashdot export LC_ALL=C; df -lkPTx squashfs; unset LC_ALL
OCI runtime exec failed: exec failed: unable to start container process: exec: "export": executable file not found in $PATH: unknown
Filesystem         Type     1024-blocks        Used  Available Capacity Mounted on
tmpfs              tmpfs        1571248       11776    1559472       1% /run
efivarfs           efivarfs         128          14        110      12% /sys/firmware/efi/efivars
/dev/dm-0          ext4      1920381208   771234760 1051522692      43% /
tmpfs              tmpfs        7856220          16    7856204       1% /dev/shm
tmpfs              tmpfs           5120           4       5116       1% /run/lock
/dev/nvme0n1p2     ext4          756800      432560     269196      62% /boot
/dev/nvme0n1p1     vfat          562080        6344     555736       2% /boot/efi
/dev/mapper/TOSHI1 ext4     13563483104 12326936856  552910948      96% /mnt/TOSHI1
/dev/mapper/WDraid ext4       960170008   593765780  317556512      66% /mnt/WDraid
tmpfs              tmpfs        1571244          84    1571160       1% /run/user/125
tmpfs              tmpfs        1571244          80    1571164       1% /run/user/1000

HDDs stay in standby

$ docker exec dashdot cat /proc/mounts 2>/dev/null > log.txt
(lots of output)

HDDs stay in standby

$ docker exec dashdot df -lkPT
df: unrecognized option: l
BusyBox v1.36.1 (2023-11-07 18:53:09 UTC) multi-call binary.

Usage: df [-PkmhTai] [-B SIZE] [-t TYPE] [FILESYSTEM]...

Print filesystem usage statistics

        -P      POSIX output format
        -k      1024-byte blocks (default)
        -m      1M-byte blocks
        -h      Human readable (e.g. 1K 243M 2G)
        -T      Print filesystem type
        -t TYPE Print only mounts of this type
        -a      Show all filesystems
        -i      Inodes
        -B SIZE Blocksize
$ docker exec dashdot df -kPT
(lots of output)

HDDs stay in standby

$ docker exec dashdot lsblk -bPo NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,UUID,ROTA,RO,RM,TRAN,SERIAL,LABEL,MODEL,OWNER 2>/dev/null > log.txt

HDDs stay in standby

$ docker exec dashdot lsblk -bPo NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT,UUID,ROTA,RO,RM,TRAN,SERIAL,LABEL,MODEL,OWNER 2>/dev/null | grep raid > log.txt
$ cat log.txt
NAME="sda" TYPE="disk" SIZE="1000204886016" FSTYPE="linux_raid_member" MOUNTPOINT="" UUID="50bcf8e3-684f-6aa2-b325-bb179aecbe3d" ROTA="1" RO="0" RM="0" TRAN="sata" SERIAL="" LABEL="richihomecl:0" MODEL="WDC WD10EZRZ-00H" OWNER="root"
NAME="md0" TYPE="raid1" SIZE="1000067825664" FSTYPE="crypto_LUKS" MOUNTPOINT="" UUID="b37c932a-cee9-4c00-b1c4-55d6c46c8e45" ROTA="1" RO="0" RM="0" TRAN="" SERIAL="" LABEL="" MODEL="" OWNER="root"
NAME="sdc1" TYPE="part" SIZE="1000203091968" FSTYPE="linux_raid_member" MOUNTPOINT="" UUID="50bcf8e3-684f-6aa2-b325-bb179aecbe3d" ROTA="1" RO="0" RM="0" TRAN="" SERIAL="" LABEL="richihomecl:0" MODEL="" OWNER="root"
NAME="md0" TYPE="raid1" SIZE="1000067825664" FSTYPE="crypto_LUKS" MOUNTPOINT="" UUID="b37c932a-cee9-4c00-b1c4-55d6c46c8e45" ROTA="1" RO="0" RM="0" TRAN="" SERIAL="" LABEL="" MODEL="" OWNER="root"
(hint: only sdc affected by this issue)
$ docker exec dashdot mdadm --export --detail /dev/sda
mdadm: /dev/sda does not appear to be an md device
$ docker exec dashdot mdadm --export --detail /dev/sdc1
mdadm: /dev/sdc1 does not appear to be an md device

HDDs stay in standby

$ docker exec dashdot mdadm --export --detail /dev/md0

HDD sdc turns on, then comes the output:

MD_LEVEL=raid1
MD_DEVICES=2
MD_METADATA=1.2
MD_UUID=50bcf8e3:684f6aa2:b325bb17:9aecbe3d
MD_DEVNAME=richihomecl:0
MD_NAME=richihomecl:0
MD_DEVICE_dev_sda_ROLE=1
MD_DEVICE_dev_sda_DEV=/dev/sda
MD_DEVICE_dev_sdc1_ROLE=0
MD_DEVICE_dev_sdc1_DEV=/dev/sdc1

Seems like sdc needs to be started to show its partition sdc1 is part of md0, whereas sda does not need to be started since it is a direct member of md0. One possible "fix" would be to readd sdc instead of sdc1 to md0.

[andres-asm]

maybe just show the last historical data until it's available again? if the drive is asleep then space won't change...