AnalogJ / scrutiny

Hard Drive S.M.A.R.T Monitoring, Historical Trends & Real World Failure Thresholds
MIT License
5.41k stars 172 forks source link

[BUG] Deleting a device in the Scrutiny UI does not delete the influxdb data and persists the device across docker restarts #572

Open delize opened 10 months ago

delize commented 10 months ago

Describe the bug When a device has been removed from a host and you wish to delete the device using

Screenshot 2024-01-30 at 12 49 57

The device gets removed initially from the UI.

If the docker container restarts, the previously deleted disk's information gets reloaded into the environment.

When using ZFS or hots-swap disks this causes incorrect information to be present in scrutiny.

Expected behavior When delete device (above) is clicked. All data from influx should be removed and the device should no longer appear in the Web UI.

Screenshots A disk that has been removed from the host, the data has been deleted, but, still exists in the Web UI.

Screenshot 2024-01-30 at 12 52 06

Log Files N/A

    scrutiny:
        container_name: scrutiny
        image: ghcr.io/analogj/scrutiny:master-omnibus
        privileged: true
        cap_add:
            - SYS_RAWIO
            - SYS_ADMIN
        # ports:
        #     - "8082:8080" # webapp
            # - "8087:8086" # influxDB admin
        environment:
            - SCRUTINY_WEB_INFLUXDB_INIT_USERNAME=${SCRUTINY_WEB_INFLUXDB_INIT_USERNAME}
            - SCRUTINY_WEB_INFLUXDB_INIT_PASSWORD=${SCRUTINY_WEB_INFLUXDB_INIT_PASSWORD}
        volumes:
            - /run/udev:/run/udev:ro
            - ${BASE_PATH}/scrutiny/config:/opt/scrutiny/config
            - ${BASE_PATH}/influxdb:/opt/scrutiny/influxdb
        restart: 'unless-stopped'
        devices:
            # - "/dev/sda"
            - "/dev/sdb"
            - "/dev/sdc"
            - "/dev/sdd"
            - "/dev/sde"
            - "/dev/sdf"
            - "/dev/sdg"
            - "/dev/sdh"
            - "/dev/nvme0"
            - "/dev/nvme1"
        networks:
            - lame
            - backend
# in another terminal trigger the collector
docker exec scrutiny scrutiny-collector-metrics run

Note that even though the drive is commented out in the above compose file, it keeps re-appearing, and also finding the /dev/sda due to the other cap_add & priv settings.

I can't currently upload the log file, but, I will be able to when I am on the same network as the device.

Docker Info

Client: Docker Engine - Community
 Version:    25.0.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.12.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 52
  Running: 48
  Paused: 0
  Stopped: 4
 Images: 49
 Server Version: 25.0.1
 Storage Driver: overlay2
  Backing Filesystem: zfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc version: v1.1.11-0-g4bccb38
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.5.0-15-generic
 Operating System: Ubuntu 23.10
 OSType: linux
 Architecture: x86_64
 CPUs: 20
 Total Memory: 94.06GiB
 Name: OMIT
 ID: OMIT
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
zuavra commented 9 months ago

I for one thought this was a feature. I don't necessarily want to lose historical data when removing a drive. There are ways in which it can still be used (with grafana for instance).

delize commented 9 months ago

If you want to "hide" a drive, that should be a different option or worded differently. Deleting by definition should be removing the drive and all data pertaining to it.

AnalogJ commented 9 months ago

You're seeing historical data after deleting a device?

https://github.com/AnalogJ/scrutiny/blob/master/webapp/backend/pkg/database/scrutiny_repository_device.go#L77-L105

That shouldn't be possible.

A device may be re-added after deletion, because Scruntiny uses smartmontools for device detection, and your device will be detected on system scan (which happens on container start).

If you'd like to delete and ignore a device you'll need to ignore it in your collector.yaml

https://github.com/AnalogJ/scrutiny/blob/master/example.collector.yaml#L38-L40

delize commented 9 months ago

While I can do that, I am not sure how helpful that would be - given that the device doesn't have a standard name showing in Scrutiny. If you check the photo again, it shows: /dev/-

Which isn't valid. 🤔

Retalak commented 2 months ago

I am having the opposite issue. I deleted drives through the UI and I cannot get them to come back even after stopping the container (which removes it) and then starting fresh again. It must be saving the database somewhere to persist, where is that?