Closed Dids closed 3 years ago
I was also facing this issue. I managed to get it running by doing the following:
docker exec -it diskover bash
pip3 install 'click==7.1.2' --force-reinstall
exit
docker restart diskover
~Of course the long-term fix is adding click==7.1.2 to requirements.txt or correcting the data being passed to click.~
Actually upon a closer look, upgrading rq in the requirements.txt file to point to >=1.8.1
Unfortunately this container is getting depreciated soon. We had been meaning to do it for a while but other things had got in the way. The developer of diskover no long supports v1 and the V2 they're planning seems to be a commercial release (plus the version of ES it requires is also end of life).
@j0nnymoe on their github repo they say
diskover v2 community will be returning to GitHub and will be fully open-source.
Would this be something linuxserver will offer? I only recently stumbled on diskover, and looking for a web based tool for monitoring disk usage
@jrlaberge Maybe, it depends if any of this comes to light, time will only tell.
I was also facing this issue. I managed to get it running by doing the following:
docker exec -it diskover bash pip3 install 'click==7.1.2' --force-reinstall exit docker restart diskover
~Of course the long-term fix is adding click==7.1.2 to requirements.txt or correcting the data being passed to click.~
Actually upon a closer look, upgrading rq in the requirements.txt file to point to >=1.8.1
Installing click==7.1.2
seems to have worked, although I don't yet have access to the web interface, but this could simply be from the initial delay (from what I hear anyway). Adding click==7.1.2
to requirements.txt
is an even better fix.
I also tried upgrading rq
to 1.8.1
(as well as 1.90
), but this fails as the redis
requirement doesn't match.
Even if this container is getting deprecated/archived, it would be great if this dependency issue could be fixed, as there's no telling when or if a new version of diskover (v2 or otherwise) will actually happen.
@Dids verify that elasticsearch is running correctly.
Did you run the sysctl command to increase memory? Look at the logs for diskover to verify what's happening.
If you're on Windows:
wsl -d docker-desktop
sysctl -w vm.max_map_count=262144
I did and I have more than one elasticsearch container running on the same system, just using different ports.
I was able to get the diskover web interface to work now, and it seems to be able to connect to elasticsearch as it asks for the indices, but it doesn't seem to be able to see any files/folder. Not sure if this is simply due to how large the folder I mounted is, or if this is something else. Nothing in the logs either.
EDIT: I deleted the previously created elasticsearch index, restarted diskover and now it seems to be crawling again, so time will tell if it works this time around! :)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Expected Behavior
The container should run with the provided documentation.
Current Behavior
Container/Diskover throws Python errors in an endless loop and never successfully starts.
Steps to Reproduce
Use the example
docker-compose.yaml
to create and launch Diskover and its dependencies.Environment
OS: Ubuntu 18.04, macOS Big Sur CPU architecture: x86_64 How docker service was installed:
Command used to create docker container (run/create/compose/screenshot)
Docker logs
The Python error repeats over and over again, indefinitely. Note that I have also tried passing in the (required?) auth token, but the end result is the same.