FATAL CONFIG error when starting container

[gooseleggs]

Starting the container with 21.4.4-[01|02|03] container, and get this

FATAL CONFIG FILE ERROR Reading the configuration file, at line 11

'logfile "/data/var-log/gvm/redis-server.log"' Can't open the log file: No such file or directory

at which time it just dies. Looks similar to another issue that you recently closed.

[LoZio]

Can you please tell me where to find those logs? I just stopped and restarted a container and now it dies after a couple of minutes, maybe the same problem

[LoZio]

Currently I have no way to start a :latest container, even with no previous data. Runs some minutes then I see the processes disappearing. UI never cames up.

[immauss]

:( Odd .... nothing has changed in more than a week.

I'm tied up pretty hard at the moment, but I may be able to look at this later today. Much later.

You can try to start an instance with a "-l" as the only option. This will put you in a shell in the container without running the start.sh. You could then verify the path exists.

I think this will work.
docker run -it --rm immauss/openvas:latest -l

-Scott

[LoZio]

:( Odd .... nothing has changed in more than a week.

I'm tied up pretty hard at the moment, but I may be able to look at this later today. Much later.

You can try to start an instance with a "-l" as the only option. This will put you in a shell in the container without running the start.sh. You could then verify the path exists.

I think this will work. docker run -it --rm immauss/openvas:latest -l

-Scott

@immauss I dont' know if something changed on Openvas side, but I cannot start any of your containers anymore. Old ones just died doing stopping and restarting, no changes to images and persistent data. Tried creating a latest and some other 21.x with new clean data volumes and none of them reaches a state where I can see the GUI. They die after some minutes. I don't know what to check to see why this happens.

[immauss]

do they work if you use "-e SKIPSYNC=true " ???

[immauss]

I think there is something whacky with the feed sync. There has been a lot of chatter on the greenbone forum about it, and running the sync from already running production container is hanging.

[immauss]

So from the discussion in the community forum, it sounds like they have outgrown their current solution. The reason given is people are hitting the DoS limits on their server.

https://community.greenbone.net/t/feeds-down/9091/9

-Scott

[LoZio]

do they work if you use "-e SKIPSYNC=true " ???

Started, even if the password for admin was set to something I have no idea... For sure not the one I passed in the command line (I use the same script since ages)

[immauss]

If it didn't get changed on startup, then it is probably admin:admin

@LoZio https://github.com/immauss/openvas/issues/82

[LoZio]

If it didn't get changed on startup, then it is probably admin:admin

@LoZio #82

I mean: I explicitly set the password on container creation And since this is a script it was always this way. But nor "admin" nor the password on the command line works. At least I get the GUI. So, back to the problem above: non syncing the feeds starts the container, so this is probably due to the link you put about the DoS being wrong on Greenbone side. Let's wait and see, is there something different we could do? Of course in the meanwhile containers must be recreated with the skip option.

[immauss]

Once you have the container up, I did drop a sync.sh in / a while ago. So you can try to get the sync to run. The 3rd or 4th time I tried, it finished on mine.

docker exec -it /sync.sh

[immauss]

@gooseleggs Can you tell me how you are starting the container? if by docker-compose, please share the yml. if by command line, please share the full docker run command.

Thanks, Scott

[gooseleggs]

I have found the problem. You might want to update the documentation. That is, you cannot have a bind mount for persistence, unless you copy the data from the /data in the container to the bind mount point. Otherwise none of the directories/database that currently resides in the container exists in the bind mount and you get the error message.

[immauss]

Yes. I realized that. That's why I was asking. I need to add a check for the directory that will populate it /data is empty. But there are some gotchyas I need to work.

I'll update the docs though for now.

Thanks, Scott

[LoZio]

Once you have the container up, I did drop a sync.sh in / a while ago. So you can try to get the sync to run. The 3rd or 4th time I tried, it finished on mine.

docker exec -it /sync.sh

Nope, it does not sync anymore. Let's wait for news on the greenbone side.

[immauss]

@LoZio According to Greenbone, they have resolved the issue: https://community.greenbone.net/t/important-ip-and-bandwith-limitations-on-community-feed/10595/46

[LoZio]

According to me they have not :-)

[immauss]

lol sorry ...

[immauss]

New release 21.4.4-05 moves the file system setup back to the start.sh. This ensure the /data folder is properly populated in an empty bind directory.

This is building now and will publish soon.

[gooseleggs]

Cannot see the -05 version on docker hub. Just download the Beta version, but this still suffers the same issue.

[gooseleggs]

Close this, as this is being worked through on #84