Ospd-openvas no longer starts

I have a docker container that runs once every few days and it’s been running perfectly fine for several weeks up until a few days ago.

One of the last lines I run in my dockerfile is the gvm-check-setup from /. However, I noticed that my docker container build failed here:

Step 7: Checking if GVM services are up and running ... 
        Starting ospd-openvas service
        Waiting for ospd-openvas service
        ERROR: ospd-openvas service did not start.
        Please check journalctl -xe

 ERROR: Your GVM-22.4.0 installation is not yet complete!

Please follow the instructions marked with FIX above and run this
script again.

When trying to start the service manually, I’ve been unable to do so successfully. The /var/log/gvm/ospd-openvas.log file just simply shows:

OSPD[1530] 2022-11-17 18:21:57,309: INFO: (ospd.main) Starting OSPd OpenVAS version 22.4.0.
OSPD[1530] 2022-11-17 18:21:57,314: INFO: (ospd.main) Shutting-down server ...

I tried to run /usr/bin/ospd-openvas from the command line itself (not even sure if I’m supposed to be able to do this) and got the following:

┌──(root㉿6f8a23a923f9)-[/]                                                                     
└─# /usr/bin/ospd-openvas                                                                       
--- Logging error ---                                                                           
Traceback (most recent call last):                                                              
  File "/usr/lib/python3.10/logging/handlers.py", line 987, in emit                             
    self.socket.send(msg)                                                                       
OSError: [Errno 9] Bad file descriptor                                                          
                                                                                                
During handling of the above exception, another exception occurred:                             
                                                                                                
Traceback (most recent call last):                                                              
  File "/usr/lib/python3.10/logging/handlers.py", line 908, in _connect_unixsocket              
    self.socket.connect(address)                                                                
FileNotFoundError: [Errno 2] No such file or directory                                          
                                                                                                
During handling of the above exception, another exception occurred:                             
                                                                                                
Traceback (most recent call last):                                                              
  File "/usr/lib/python3.10/logging/handlers.py", line 990, in emit                             
    self._connect_unixsocket(self.address)                                                      
  File "/usr/lib/python3.10/logging/handlers.py", line 919, in _connect_unixsocket              
    self.socket.connect(address)                                                                
FileNotFoundError: [Errno 2] No such file or directory                                          
Call stack:                                                                                     
  File "/usr/bin/ospd-openvas", line 8, in <module>                                             
    sys.exit(main())                                                                            
  File "/usr/lib/python3/dist-packages/ospd_openvas/daemon.py", line 1255, in main              
    daemon_main('OSPD - openvas', OSPDopenvas, NotusParser())                                   
  File "/usr/lib/python3/dist-packages/ospd/main.py", line 155, in main                         
    logger.info(                                                                                

... error continues below ...

I’m pretty tempted to just move over completely to the openvas docker containers, but I was hoping to tackle this project next month instead of now.

Any thoughts on other ways I can troubleshoot what may be going on? I’m sure a lot of what I’m doing here is unnecessary, but this has been my process for installing/configuring openvas in my docker container:

  apt install openvas &&
  service postgresql start &&
  gvm-setup | tee ~/.openvas_install_logs.txt &&
  sed -i"" 's/--port 9392/--port 9392 --no-redirect/g' /lib/systemd/system/gsad.service &&
  runuser -u _gvm -- gvm-manage-certs -a -f &&
  runuser -u _gvm -- greenbone-nvt-sync &&
  runuser -u _gvm -- greenbone-feed-sync --type CERT &&
  runuser -u _gvm -- greenbone-feed-sync --type SCAP &&
  runuser -u postgres -- /usr/share/gvm/create-postgresql-database &&
  gvm-check-setup &&
  while ! grep daba56c8-73ec-11df-a475-002264764cea /var/log/gvm/gvmd.log; do
    tail -n 20 /var/log/gvm/gvmd.log
    sleep 10
  done &&
  while ! grep "Updating DFN-CERT CVSS max succeeded." /var/log/gvm/gvmd.log; do
    echo "Waiting on DFN-CERT updates"
    sleep 10
  done &&
  while ! grep "Updating CERT-Bund CVSS max succeeded" /var/log/gvm/gvmd.log; do
    echo "Waiting on CERT-Bund update"
    sleep 10
  done &&
  while ! grep "Updating SCAP info succeeded" /var/log/gvm/gvmd.log; do
    echo "Waiting on SCAP updates"
    sleep 10
  done &&
  openvas -u

Most of the waiting in the above statements are to try to get the container as “up-to-date” as possible before pushing it.

Again, pretty inefficient I’d assume but it’s always worked and got the job done. Planning to move to the containers soon, but was hoping for some help with the ospd-openvas service that I can’t seem to get running anymore.

Using the latest kali 2202.4 container to do this on.

How did you start ospd-openvas and with which arguments?

Currently I suspect you can’t write to the log directory anymore but that’s only a guess.

1 Like

In my installation and “provisioning” of openvas, I usually don’t manually start ospd-openvas. I usually just run gvm-check-setup and that typically starts it for me.

For troubleshooting purposes, however, I did try starting it with the following: systemctl start ospd-openvas and got those error messages.

When starting the service and changing the log level from INFO to DEBUG, I’m seeing the following in /var/log/gvm/ospd-openvas.log:

OSPD[272] 2022-11-19 22:24:52,632: DEBUG: (gnupg) 274: gpg --status-fd 2 --no-tty --no-verbose --fixed-list-mode --batch --with-colons --homedir /etc/openvas/gnupg --version
OSPD[272] 2022-11-19 22:24:52,632: DEBUG: (gnupg) stderr reader: <Thread(Thread-1 (_read_response), initial daemon)>
OSPD[272] 2022-11-19 22:24:52,633: DEBUG: (gnupg) stdout reader: <Thread(Thread-2 (_read_data), initial daemon)>
OSPD[272] 2022-11-19 22:24:52,634: DEBUG: (gnupg) chunk: b'gpg (GnuPG) 2.2.40\nlibgcrypt 1.10.1\nCopyright (C) 2022 g10 Code GmbH\nLicense GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.\n\n'
OSPD[272] 2022-11-19 22:24:52,634: DEBUG: (gnupg) gpg: WARNING: unsafe ownership on homedir '/etc/openvas/gnupg'
OSPD[272] 2022-11-19 22:24:52,654: INFO: (ospd.main) Starting OSPd OpenVAS version 22.4.0.
OSPD[272] 2022-11-19 22:24:52,657: DEBUG: (ospd.main) Performing exit clean up
OSPD[272] 2022-11-19 22:24:52,657: DEBUG: (ospd.ospd) All scans stopped and daemon clean and ready to exit
OSPD[272] 2022-11-19 22:24:52,657: INFO: (ospd.main) Shutting-down server ...
OSPD[272] 2022-11-19 22:24:52,657: DEBUG: (ospd.main) Finishing daemon process

Not quite sure what this means, unfortunately.

I don’t have a clue what’s happening here. It seems that ospd-openvas is stopped by intention from the last logs. Also the initial error message isn’t shown.

Thanks @bricks. I reverted back to kali-latest-release and all is well now. Something must have gotten pushed out in kali-rolling that contributed to this issue.

Very interesting. The issue that was fixed when switching to kali-last-release from kali-rolling is now broken again:

2022-11-26T07:32:51.7438690Z Step 6: Checking Greenbone Security Assistant (GSA) ... 
2022-11-26T07:32:51.7688832Z e[91mOops, secure memory pool already initialized
2022-11-26T07:32:51.7725389Z e[0m        OK: Greenbone Security Assistant is present in version 22.04.0~git.
2022-11-26T07:32:51.7729449Z Step 7: Checking if GVM services are up and running ... 
2022-11-26T07:32:51.8977639Z         Starting ospd-openvas service
2022-11-26T07:33:38.2751417Z         Waiting for ospd-openvas service
2022-11-26T07:33:48.4006404Z         ERROR: ospd-openvas service did not start.
2022-11-26T07:33:48.4006914Z         Please check journalctl -xe
2022-11-26T07:33:48.4007144Z 
2022-11-26T07:33:48.4007450Z  ERROR: Your GVM-22.4.0 installation is not yet complete!
2022-11-26T07:33:48.4007709Z 
2022-11-26T07:33:48.4008217Z Please follow the instructions marked with FIX above and run this
2022-11-26T07:33:48.4029436Z script again.