ThinkRoot

bine ați navigat pe insula mea de pe internet

Am instalat Scrutiny și ambele disk-uri au apărut ca Failed

Recent am făcut un mic server pe un Intel NUC. Pe el am instalat câteva servicii printre care și Scrutiny care să îmi monitorizeze stocarea.

După o zi am decis să pun acest serviciu și pe calculator pentru monitorizarea disk-urilor, fără să fie nevoie să intru manual în smartctl periodic.

Ce părea simplu la instalare s-a dovedit puțin mai complicat: ambele drive-uri au apărut ca Failed în interfață imediat după primul scan. Spoiler: niciunul nu era defect.

În calculator am două disk-uri, și acestea sunt:

Instalarea Scrutiny

Scrutiny rulează ca două componente separate în același container: un collector care citește datele S.M.A.R.T. și un web server care le afișează. Există o imagine all-in-one (ghcr.io/analogj/scrutiny:master-omnibus) care le include pe amândouă.

Creez directorul de configurare:

mkdir -p ~/.services/scrutiny/config

~/.services/scrutiny/docker-compose.yml:

services:
  scrutiny:
    image: ghcr.io/analogj/scrutiny:master-omnibus
    container_name: scrutiny
    restart: unless-stopped
    cap_add:
      - SYS_RAWIO
      - SYS_ADMIN
    ports:
      - "8088:8080"
    volumes:
      - /run/udev:/run/udev:ro
      - ./config:/opt/scrutiny/config
    devices:
      - /dev/nvme0:/dev/nvme0
      - /dev/sda:/dev/sda
cd ~/.services/scrutiny
docker compose up -d

După instalare și pornire, Scrutiny e accesibil la http://localhost:8088. Și acum au început și problemele.

Problema 1 - SSD-ul NVMe apare ca Failed

La primul scan, SSD-ul ADATA Legend 710 a apărut imediat ca Failed cu o eroare de tip checksum. Am verificat cu smartctl direct:

sudo smartctl -a /dev/nvme0 -d nvme

Output-ul era clar: drive-ul e sănătos, SMART overall-health self-assessment: PASSED, temperatură 30°C, zero erori. Scrutiny vedea altceva.

În docker-compose.yml aveam inițial doar SYS_RAWIO în cap_add. Fără SYS_ADMIN, containerul nu poate citi corect datele NVMe prin interfața kernel-ului, ceea ce genera erori de checksum la parsarea atributelor SMART.

Am adăugat SYS_ADMIN în cap_add:

cap_add:
  - SYS_RAWIO
  - SYS_ADMIN

Restart container:

docker compose down
docker compose up -d

Eroarea de checksum a dispărut după următorul scan.

Problema 2 - HDD-ul Seagate apare ca Failed

Chiar și după rezolvarea problemei NVMe, HDD-ul Seagate ST6000VX009 continua să apară ca Failed. Atributele incriminate erau Seek Error Rate (ID 7) și Read Error Rate (ID 1), ambele cu valori aparent catastrofale.

Aceasta e o problemă cunoscută cu drive-urile Seagate. Seagate folosește un format proprietar pentru aceste atribute: valorile brute sunt de fapt contoare pe 48 de biți care encodează atât numărul de erori cât și numărul total de operații. Scrutiny (și de fapt majoritatea tool-urilor S.M.A.R.T.) le interpretează greșit ca valori simple, rezultând cifre uriașe care declanșează alarme false.

Dacă rulezi sudo smartctl -a /dev/sda și drive-ul arată SMART overall-health self-assessment test result: PASSED cu Reallocated Sectors, Pending Sectors și Uncorrectable Errors la zero, drive-ul e sănătos.

Scrutiny stochează statusul drive-urilor într-o bază de date SQLite la /opt/scrutiny/config/scrutiny.db. Resetez manual statusul fals:

Pasul 1 - intru în container:

docker exec -it scrutiny /bin/bash

Pasul 2 - instalez sqlite3 (nu e inclus în imagine, nu persistă după restart):

apt-get update && apt-get install -y sqlite3

Pasul 3 - resetez statusul:

sqlite3 /opt/scrutiny/config/scrutiny.db "UPDATE devices SET device_status = null;"

Pasul 4 - rulez manual collector-ul:

/opt/scrutiny/bin/scrutiny-collector-metrics run

Pasul 5 - ies din container:

exit

Atenție: SYS_ADMIN trebuie să fie deja prezent în cap_add înainte de acest pas. Dacă faci resetul înainte de fix, collector-ul va rescrie imediat statusul Failed și trebuie să repeți toată procedura.

Verificare suplimentară - SMART extended test pe HDD

Deși eram convins că e o alertă falsă, am rulat și un test extended S.M.A.R.T. complet pe HDD, ca să fiu sigur:

sudo smartctl -t long /dev/sda

Testul durează în funcție de dimensiunea drive-ului - pentru un HDD de 6TB, estimarea a fost de 651 de minute (~10 ore). La final:

sudo smartctl -a /dev/sda | grep -A 1 "SMART overall"

Rezultat: Completed without error - drive-ul e perfect sănătos.

Rezultatul final

După toate corecțiile, ambele drive-uri apar cu status verde în Scrutiny:

Scrutiny rulează acum cu restart: unless-stopped, scanează automat drive-urile și trimite notificări prin email dacă apare ceva real.

Rezumat

Două lucruri de reținut dacă instalezi Scrutiny cu drive-uri NVMe sau Seagate:

1. NVMe necesită SYS_ADMIN în cap_add, nu doar SYS_RAWIO. Fără el, citirea atributelor NVMe eșuează cu erori de checksum.

2. Seagate Seek/Read Error Rate sunt fals pozitive. Seagate encodează statistici complexe în atributele S.M.A.R.T. pe care Scrutiny le interpretează greșit. Verifică întotdeauna smartctl direct și uită-te la atributele cu adevărat relevante: Reallocated Sectors (ID 5), Pending Sectors (ID 197) și Uncorrectable Errors (ID 198). Dacă acestea sunt la zero și testul overall e PASSED, drive-ul e sănătos.

⬅ The one before
Am mutat serviciile self-hosted de pe Linux Mint pe un Intel NUC

Up next ➡
Ce este IndieWeb-ul și de ce ar trebui să-ți pese