Closed DRIgnazGortngschirl closed 1 year ago
I got the same problem
Thank you.
I've recently added those health checks to help diagnose these problems. Openvas is dependent on redis. So if redis dies, openvas will too.
Can you give me some details on your environment? ( OS, CPU, Memory etc.)
Also make sure you are pulling the latest. I've tested it just now and it works fine on my three test systems. ( A linode with docker-ce & 8G of RAM, RaspberryPi 4 with 4G of RAM and Docker Desktop on my Mac. )
All start and run fine.
I did a little more testing with memory limits and found that if I restrict the container to 256M of memory, I see the same results. So please make sure you have at least 256M of available memory. You can also try to add the memory reservation directive to the compose. This is something I will likely add in the near future to the default. I've long suspected that low memory was causing other issues, which is why I added the extra healthchecks to help find what was dying easier.
Below is snipped from a working docker-compose with memory limits. Obviously, you can set the high limit to whatever you have available, the reservation should ensure there's enough to get things going.. I'm not sure what happens if that memory is not available. I assume docker would refuse to start it, but not sure.
version: "3.3"
services:
openvas:
mem_limit: 512m
mem_reservation: 384m
cpus: 1
ports:
Can you give me some details on your environment? ( OS, CPU, Memory etc.)
Debian GNU/Linux 11 AMD EPYC 7282 (8) @ 2.794GHz Memory 32 GB SSD 1,2 TB
I did assign 4 cores and also 4 GB RAM, but that did not work for me.
mem_limit: 4096m
mem_reservation: 4000m
cpus: 4
Also updated the image tag to latest
Maybe something interesting to add here.
openvas | ==> /usr/local/var/log/gvm/gvmd.log <==
openvas | md main:MESSAGE:2022-12-17 10h40.28 utc:1927: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h40.28 utc:1927: Getting scanners.
openvas | md main:MESSAGE:2022-12-17 10h40.30 utc:1933: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h40.30 utc:1933: Verifying scanner.
openvas |
openvas | ==> /usr/local/var/log/gvm/healthchecks.log <==
openvas | Healthchecks completed with no issues.
openvas |
openvas | ==> /usr/local/var/log/gvm/gvmd.log <==
openvas | md main:MESSAGE:2022-12-17 10h41.31 utc:1990: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h41.31 utc:1990: Getting scanners.
openvas | md main:MESSAGE:2022-12-17 10h41.32 utc:1999: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h41.32 utc:1999: Verifying scanner.
openvas |
openvas | ==> /usr/local/var/log/gvm/healthchecks.log <==
openvas | Healthchecks completed with no issues.
openvas |
openvas | ==> /usr/local/var/log/gvm/gvmd.log <==
openvas | md main:MESSAGE:2022-12-17 10h42.33 utc:2055: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h42.33 utc:2055: Getting scanners.
openvas | md main:MESSAGE:2022-12-17 10h42.36 utc:2061: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h42.36 utc:2061: Verifying scanner.
openvas |
openvas | ==> /usr/local/var/log/gvm/healthchecks.log <==
openvas | Healthchecks completed with no issues.
openvas |
openvas | ==> /usr/local/var/log/gvm/gvmd.log <==
openvas | md main:MESSAGE:2022-12-17 10h43.37 utc:2118: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h43.37 utc:2118: Getting scanners.
openvas | md main:MESSAGE:2022-12-17 10h43.39 utc:2124: Greenbone Vulnerability Manager version 22.4.0~dev1 (DB revision 250)
openvas | md manage: INFO:2022-12-17 10h43.39 utc:2124: Verifying scanner.
openvas |
openvas | ==> /usr/local/var/log/gvm/healthchecks.log <==
openvas | HEALTHECHECK FAILED !
openvas | These services failed
openvas | openvas redis
I did forget to stop the container and checked the logs new once again as I saw the Web interface is up, but login is not working.
How about Disk space?
Can you remove the volume and try completely fresh?
Thanks, Scott
Maybe I am missing something, but did it like.
docker-compose stop && docker-compose rm && docker volumes prune
I think that would work ..... But I would just do a "docker volume rm openvas" after removing the container to be sure the volume is gone. I take it that did not resolve the problem .....
Without updating it, the service is now running as expected. I was not familiar with Docker, but after executing the docker-compose it runs fluently for me. Thanks for your work @immauss
Next question is, when I am looking into the logs of the container, the latest message is: "Healthchecks completed with no issues". However if I run docker ps the status shows "Up x minutes (unhealty)". From my point everything is right, the GUI works and the scan too. So it should show up healthy, right?
THat is odd. It should show healthy. I sounds like everything is running. Does it stay that way if you restart it too ?
-Scott
Everything works now properly.
Thanks for the follow up!
Hi!
I am getting with a completly clean and new install via docker-compose the follwoing error.