#Grsync automation update
#Grsync automation verification

Failure to do this and moving on to the next sync will certainly break things!įollows nvt sync and usually completes without error. lock file will be left in the /opt/gvm/var/run/*.lock this lock file will need to be removed and then run the greenbone-nvt-sync command again.

#Grsync automation update

Update Process (Paths based on Debian build from source): This software is really good and I have contributed to many open source projects so a ton of time goes in to building and maintaining it so thank you for providing it!! Please feel free to expand on this further. Here is my write-up regarding my experience with this application in regard to feed updates.

#Grsync automation verification

Rsync error: error in socket IO (code 10) at clientserver.c(127) [Receiver=3.1.3Īfter hours and hours of going through loads and loads of this I have found that all services can be green yet the web interface not be ready, scanner failing verification etc. Please help as this results in having to rollback and a system that works fine but can’t update. It’s not a network connectivity issue on my side I have low latency and a 1GB synchronous connection to the Internet. I am really trying to understand GVM and why this is occurring. Not sure why this process continually dies like this.

Rsync error: error in socket IO (code 10) at clientserver.c(127)