[BUG] Container will not start using Run command or Start command

[dustinbird]

Please attach large files to the report instead of pasting the contents into the report.

Describe the bug I have attempted to pull the latest Docker image down to my OpenSuse Leap server as part of the weekly update (although last week was missed). The container downloads ok but will not run. After around five minutes Docker PS shows no container running.

To Reproduce Steps to reproduce the behavior:

1. Old container stopped and removed using "Docker system prune -a",

2. new container downloaded using "docker run --detach --publish 8443:9392 -e PASSWORD="REDACTED" --volume openvas:/data -e HTTPS=true --name openvas immauss/openvas:latest"

3. Process monitored with "watch Docker ps"

4. Also attempted step 2 above with addition of "-e SKIPSYNC=true"

5. Container also attempted to run (once downloaded as per step 2) using "docker start openvas"

6. server rebooted multiple times and above attempted again

7. When did the issue occur?

   • the container failed to start

Expected behavior Container to run. Other two same spec servers have same image running with no issues at present, although one box did give the same issue, but seemed to just work on a later attempt. Before I could log the issue here. I expected the same with this instance but has not started even though container downloaded and attempted for 3 days.

Environment (please complete the following information):

• OS: OpenSUSE Leap 15.5
• Container environment used with version: docker

logs ( commands assume the container name is 'openvas' ) Please attach the output from one of the following commands:

docker

Log Attached

Please "attach" the file instead of pasting the contents to the issue. Docker Logs.txt

Additional context gvmd=v23.8.1 gvm_libs=v22.10.0 openvas=v23.8.5 openvas_smb=v22.5.6 notus_scanner=v22.6.4 gsa=v23.2.1 gsad=v22.11.0 ospd=v21.4.4 ospd_openvas=v22.7.1 pg_gvm=v22.6.5 python_gvm=v24.7.0 gvm_tools=v24.7.0 greenbone_feed_sync=v24.3.0

[immauss]

This is most likely due to the problems with the rsync server for the notus files. It is back up now, so the problem should be resolved. If not, please let me know. In the future, if feed sync is causing a startup failure, you can start the container with

-e SKIPSYNC=true

This will allow the container to start and use only the internal DB. WHile this might not be as up-to-date, it will atleast run. :)

-Scott

[dustinbird]

Sorry but I have been trying that switch (that detail was hidden in point 4 above) this resolved a similar situation in the past but has not worked this week for me. I am attempting again now though as you have suggested the problem may be resolved.

[dustinbird]

No this is still failing with SKIPSYNC.

[dustinbird]

I have this working on another Leap 15.5 server (running a similar role, NOT a replacement for the other server) patched to the same level today running the docker image downloaded and run today, but the same fails on the other server. Could this be something else server based that could be causing this?

Both servers have the following details on GVM versions:

gvmd=v23.8.1 gvm_libs=v22.10.0 openvas=v23.8.5 openvas_smb=v22.5.6 notus_scanner=v22.6.4 gsa=v23.2.1 gsad=v22.11.0 ospd=v21.4.4 ospd_openvas=v22.7.1 pg_gvm=v22.6.5 python_gvm=v24.7.0 gvm_tools=v24.7.0 greenbone_feed_sync=v24.3.0

[immauss]

Please give the "latest" a try. I think it might be the same as #283

[immauss]

There is also a "beta" now with even better fixes that may resolve the issue. But since I've not heard from you in a bit, I'm going to assume the newer images resolve the issue. If not, please opena new issue.

Thanks, Scott