This is an archived version of the documentation for SonarQube-6.7.
See the Latest Documentation for current functionality.

Release 6.6 Upgrade Notes

Support for Microsoft SQLServer 2012 is dropped

Instead, support for Microsoft SQLServer 2016 has been added. See images/ SONAR-9745 - Drop support of Microsoft SQLServer 2012 Closed and images/ SONAR-8632 - Add support of Microsoft SQLServer 2016 Closed .

Oracle Clean-up

images/ SONAR-9763 - Reduce time spent on DB migration steps hotspot Closed On Oracle the database columns to be dropped are now marked as UNUSED and are not physically dropped anymore. To reclaim disk space, Oracle administrators have to manually drop these unused columns. SQL request is ALTER TABLE foo DROP UNUSED COLUMNS. The concerned tables are listed in the table all_unused_col_tabs.

Non-hierarchical project structure no longer supported

Prior to 6.6, the only constraint was to have a hierarchical file hierarchy inside each modules. To be precise, it means all files part of a module were required to be physical children of the module base directory. There was no check that modules themselves were nested under their parent module (and ultimately root project) base directory.

Since 6.6, we are enforcing a strict file tree, originating from the project base directory. See images/ SONAR-9835 - Possible NPE in global sensors when some analyzed files are located outside of project baseDir Closed

This change is mainly affecting "flat" Maven projects layout, and will possibly be addressed by images/ MSONAR-164 - Make flat project layout working out-of-the-box with SonarQube 6.6+ Closed

Can't run as root

It has always been a bad idea to run SonarQube as root, but with the upgrade in this version of ElasticSearch, it is no longer possible. If you try to run SonarQube as root, the ElasticSearch startup will fail and the SonarQube instance will shut back down.

Additional OS-level settings for Linux

If you're running on Linux, you must now ensure that:

  • vm.max_map_count is greater or equal to 262144

  • fs.file-max is greater or equal to 65536

  • the user running SonarQube can open at least 65536 file descriptors

  • the user running SonarQube can open at least 2048 threads

You can see the values with the following commands :

sysctl vm.max_map_count
sysctl fs.file-max
ulimit -n
ulimit -u

You can set them dynamically for the current session by running the following commands as root:

sysctl -w vm.max_map_count=262144
sysctl -w fs.file-max=65536
ulimit -n 65536
ulimit -u 2048

images/s/en_GB/7402/131c587a84e4ee088cb3d1cec7ecd765481c9c79/_/images/icons/emoticons/warning.png To set these values more permanently, you must update either /etc/sysctl.d/99-sonarqube.conf (or /etc/sysctl.conf as you wish) to reflect these values.

If the user running SonarQube (sonarqube in this example) does not have the permission to have at least 65536 open descriptors, you must insert this line in /etc/limits.d/99-sonarqube.conf (or /etc/limits.conf as you wish) :

sonarqube - nofile 65536
sonarqube - nproc 2048

You can get more detail in the Elasticsearch documentation.

seccomp filter

By default, Elasticsearch uses seccomp filter. On most distributions this feature is activated in the kernel, however on distribution like Red Hat Linux 6 this feature is deactivated. If you are using a distribution without this feature and you cannot upgrade to a newer version with seccomp activated, you have to explicitly deactivate this security layer by updating in :

You can check if seccomp is available on your kernel with :

$ grep SECCOMP /boot/config-$(uname -r)

If your kernel has seccomp, you will see :


For more detail, see the Elasticsearch documentation .