Skip to content
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

[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 this issue Jan 30, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@delize
Copy link

delize commented Jan 30, 2024

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
@delize delize added the bug Something isn't working label Jan 30, 2024
@zuavra
Copy link

zuavra commented Feb 25, 2024

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
Copy link
Author

delize commented Feb 25, 2024

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
Copy link
Owner

AnalogJ commented Feb 25, 2024

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
Copy link
Author

delize commented Feb 29, 2024

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
Copy link

Retalak commented Sep 27, 2024

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?

@mrtumnus
Copy link

mrtumnus commented Dec 12, 2024

I'm encountering this on master#affe05e. I have three drives at the top of the dashboard named /dev/ -, and I can't get rid of them. I went digging around in influxdb, but couldn't find any reference to drives that don't exist (all the device wwn's matched installed drives).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants