Fix for reports not displaying in GVM 20.8 due to JavaScript errors


First, thanks so much to Greenbone for making this remarkable tool available to the community. It is really appreciated.

I installed GVM 20.8 from source tar balls on Debian 10, running all components as root. The problem is described in the following GitHub topic (GSA is throwing JavaScript exceptions for an undefined report element within the report entity):

Greenbone GSA issue 2389


There is a permission problem on the following directory:


The missing elements within the outer <report id="…’> are created by the report formatting scripts. These scripts could not run because the above directory has no read or execute permissions for anyone but the directory owner. The scripts are run as “nobody” in “nogroup”.

Run the following command:

chmod 755 INSTALL_DIR/var/lib/gvm/gvmd/report_formats

You do not need to restart any Greenbone components. The fix will take effect immediately.

A better solution would change whatever is necessary in the cmake files but that fix eludes me.

Suggested changes to Greenbone code:

  1. The system call in run_report_format_script() in manage_sql_report_formats.c around line 4638 currently ignores the shell return code. It would be better if this wasn’t the case as no report content was being generated (but no error was detected by gvmd) which caused the downstream JavaScript errors in the web browser.

  2. It would be nice to be able to run gvmd in the gdb debugger. I couldn’t follow the children after they got forked off. I tried the gdb command “set follow-fork-mode child” but that didn’t work. Having to add masses of debug log statements to narrow down the problem was not optimal. Apache provides a way to run their web server in non-forking mode. I looked into this for gvmd but see what a large job that would be since there are fork() calls everywhere.

Debugging tips (some things that might help others when debugging Greenbone code):

PART 1 - Debug logging in gvmd:

Log levels are controlled with the following file:


Copy gvmd_log.conf to gvmd_log.conf.orig

Change any sections that write to the gvmd.log file so that “level=128” and restart gvmd.

Copy gvmd_log.conf to gvmd_log.conf.debug

Any time you run make install in gvmd, gvmd_log.conf will be overwritten, so copy back the debug
version of the config file, as needed.

Add additional logging to gvmd source code with calls to g_debug(). It works like printf() so it is easy to
create log messages with strings and numeric data.

The log file location:


PART 2 - Create non-minified JavaScript files

Greenbone bundles up and installs the JavaScript files used by the gsad web server
in the following location:


Most of the Greenbone-specific code is found in “main.*.chunk.js”. This file is minified for use in production environments. This makes JavaScript debugging in the web browser tedious, at best. To create a non-minified version of this file, edit the following configuration file:


Search for the string “minimize:”. It will be in the “optimization:” section.
The default setting is “minimize: isEnvProduction,”
Comment this line out using “//” and add the following line instead:

minimize: false,

Rebuild and reinstall gsa.

Note that this tip will not de-minify all JavaScript code being installed and there are many other
minified packages (the React code, for example) that require different procedures if you want to
debug that code.

Also note that there is probably a clever way to create a non-production build in cmake that does not
require editing the webpack config file which eluded me.


Thanks for summarizing the GSA issue with the scan_run_status.

It is much easier to debug gvmd (and also gsad) when running in foreground. You can just use the -f flag for example gvmd -f.

For debugging our web application it is best to run the dedicated development web server. How to do that is described here.

1 Like

I’m not sure how that would work, because gvmd needs the forks to do stuff in the background, like serving GMP to the client, or managing a task started via GMP.

Best option is probably putting a sleep somewhere and attaching to the sleeping process from gdb.

1 Like