[BUG] Could not retrieve device information for sda

[soratoyuki]

Describe the bug
Preemptive apologies. I'm in a little over my head to be honest and still reasonably unfamiliar with Linux and command line. I'm following the manual installation guide since I'm using Xubuntu directly instead of Docker. There's several other similar issues posted, but they all seem to be Docker-specific and have Docker-specific solutions.

1. localhost:8080 "loads" when I run $ /opt/scrutiny/bin/scrutiny-web-linux-amd64 start --config /opt/scrutiny/config/scrutiny.yaml but not once I stop the command (ctrl+c or by closing terminal). I assume this is a very dumb error on my part with an embarrassingly simple solution. More relevantly, while the webpage loads, no actual information populates. I assume this is because:

2. Running $ /opt/scrutiny/bin/scrutiny-collector-metrics-linux-amd64 run --api-endpoint "http://localhost:8080" returns "ERRO[0000] Could not retrieve device information for sda: exit status 2 type=metrics"
   I have three drives installed, so along with sda, sdb and nvme0 also return with the same error. $ smartctl --scan does return all 3 drives

Expected behavior
The Web UI to run without having an open terminal for when I run $ /opt/scrutiny/bin/scrutiny-web-linux-amd64 start --config /opt/scrutiny/config/scrutiny.yaml, and for the Web UI to actually populate information.

Screenshots
If applicable, add screenshots to help explain your problem.

Log Files

Since I'm not using Docker, I used $scrutiny-collector-metrics run --debug --log-file /tmp/collector.log in terminal, which returned "scrutiny-collector-metrics: command not found" Sorry!

[CoordSpace]

I'm dealing with what might be the same issue. I'm getting SMART information updates in the webUI for every drive in Scrutiny except for sda. The system has been happily working for over a year but on "April 17, 2024 - 19:00" sda just stopped updating.

It's worth noting that sda and sdb are the same model of drive and data on both drives is accessible with no issues.

Looking over the logs from the container, I see a number of errors being reported upon startup.

scrutiny  | time="2024-05-08T22:16:39Z" level=error msg="smartctl returned an error code (1) while processing sda\n" type=metrics
scrutiny  | time="2024-05-08T22:16:39Z" level=error msg="smartctl could not parse commandline" type=metrics
scrutiny  | time="2024-05-08T22:16:39Z" level=error msg="Cannot parse SMART data invalid character 'S' looking for beginning of value" type=web
scrutiny  | time="2024-05-08T22:16:39Z" level=error clientIP="::1" hostname=270a9b0f6657 latency=1 method=POST path=/api/device/0x5000c500ad907b7b/smart referer= respLength=17 statusCode=500 type=web userAgent=Go-http-client/1.1
scrutiny  | time="2024-05-08T22:17:15Z" level=error msg="smartctl returned an error code (4) while processing sdf\n" type=metrics
scrutiny  | time="2024-05-08T22:17:15Z" level=error msg="smartctl detected a checksum error" type=metrics

Running the smartctl --xall --json /dev/sda command from the logs manually outside of the container yields all the drive SMART data as expected. Running it within the container using the smartctl that's included in the container results in this:

Smartctl: Exception: json.cpp(313): Assertion failed: p->type == nt_array
Please inform smartmontools-support@listi.jpberlin.de, including output of smartctl -V.

So something is up with the version of smartctl that's packaged in the official docker container.

For the sake of completeness, here's the output of smartctl -V for the copy of smartctl that's included in the latest version of ghcr.io/analogj/scrutiny:master-omnibus

smartctl 7.3 2022-02-28 r5338 [x86_64-linux-5.15.0-105-generic] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
[...]
smartmontools release 7.3 dated 2022-02-28 at 16:33:40 UTC
smartmontools SVN rev 5338 dated 2022-02-28 at 16:34:26
smartmontools build host: x86_64-pc-linux-gnu
smartmontools build with: C++11, GCC 12.2.0
smartmontools configure arguments: [hidden in reproducible builds]
reproducible build SOURCE_DATE_EPOCH: 1665910132 (2022-10-16 08:48:52)

Here's the version info for the functional version of smartctl that I have installed on my host OS:

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-105-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
[...]
smartmontools release 7.2 dated 2020-12-30 at 16:48:30 UTC
smartmontools SVN rev 5155 dated 2020-12-30 at 16:49:18
smartmontools build host: x86_64-pc-linux-gnu
smartmontools build with: C++17, GCC 11.4.0

Obligatory OS and Docker Compose Information

OS: Ubuntu 22.04.4 LTS
Docker: version 26.1.0, build 9714adc

  scrutiny:
    image: ghcr.io/analogj/scrutiny:master-omnibus
    container_name: scrutiny
    networks:
      - frontend
    cap_add:
      - SYS_RAWIO
    environment:
      - DEBUG=false
      - SCRUTINY_LOG_FILE=/opt/scrutiny/config/web.log
    volumes:
      - ${APPDIR}/scrutiny/config:/opt/scrutiny/config
      - ${APPDIR}/scrutiny/influxdb:/opt/scrutiny/influxdb
      - /run/udev:/run/udev:ro
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/sdc
      - /dev/sdd
      - /dev/sde
      - /dev/sdf
    labels:
      # Web UI
      - traefik.http.routers.scrutiny.rule=Host(`smart.${DOMAIN_NAME}`)
      - traefik.http.routers.scrutiny.entrypoints=websecure
      - traefik.http.routers.scrutiny.tls.certresolver=letsencrypt
      - traefik.http.routers.scrutiny.service=scrutiny-serv
      - traefik.http.services.scrutiny-serv.loadbalancer.server.port=8080