Warnings after installation of SonarQube Developer 7.3


(Norman) #1

Hi there,

I just registered here because I have some issues after an Sonarqube installation and I’m looking for help.

I have installed Sonarqube Developer Edition 7.3 on an Oracle Linux 7.2 server. The service is running, but I still get some warnings that I was not able to get rid of.

1) In es.log

2018.09.10 13:49:53 WARN es[][o.e.b.BootstrapChecks] max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]

I added the following lines to the file /etc/security/limits.d/20-nproc.conf, but the warning still is shown when starting the service.

sonar - nofile 65536
sonar - nproc 2048

The settings for vm.max_map_count and fs.file-max are set in /etc/sysctl.d/99-sonarqube.conf:

vm.max_map_count=800000
fs.file-max=300000

So where is this stupid warning still getting the 4096 from?

2) In ce.log

2018.09.10 13:50:11 WARN ce[][o.s.c.p.ComponentKeys] Bad component key: org.sonar.java.externalreport.ExternalRulesDefinition@77cc40bb. Please implement toString() method on class org.sonar.java.externalreport.ExternalRulesDefinition
2018.09.10 13:50:11 WARN ce[][o.s.c.p.ComponentKeys] Bad component key: org.sonar.java.externalreport.ExternalRulesDefinition@561939c9. Please implement toString() method on class org.sonar.java.externalreport.ExternalRulesDefinition
2018.09.10 13:50:11 WARN ce[][o.s.c.p.ComponentKeys] Bad component key: org.sonar.java.externalreport.ExternalRulesDefinition@149a054f. Please implement toString() method on class org.sonar.java.externalreport.ExternalRulesDefinition

I found this: Initial setup integration failing
and did what Julien Henry suggested at the bottom:

  • Stop the SQ server
  • Remove the data/es folder (was named es5 in my case)
  • Restart

but the warnings are still shown.

3) In web.log

2018.09.10 13:50:01 WARN web[][o.s.c.p.ComponentKeys] Bad component key: org.sonar.java.externalreport.ExternalRulesDefinition@7d792f6b. Please implement toString() method on class org.sonar.java.externalreport.ExternalRulesDefinition
2018.09.10 13:50:01 WARN web[][o.s.c.p.ComponentKeys] Bad component key: org.sonar.java.externalreport.ExternalRulesDefinition@3122b53f. Please implement toString() method on class org.sonar.java.externalreport.ExternalRulesDefinition
2018.09.10 13:50:01 WARN web[][o.s.c.p.ComponentKeys] Bad component key: org.sonar.java.externalreport.ExternalRulesDefinition@4a679d68. Please implement toString() method on class org.sonar.java.externalreport.ExternalRulesDefinition
2018.09.10 13:50:02 WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/plugins/download
2018.09.10 13:50:02 WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/security_reports/show
2018.09.10 13:50:02 WARN web[][o.s.a.s.w.WebService$Action] The response example is not set on action api/support/info

For the first 3 lines, see #2
For the “The response example is not set on action”, Google did not really lead to a hint how this could be solved.

Any help would be greatly appreciated.

Thanks
-Norman


(G Ann Campbell) #2

Hi Norman,

According to the requirements docs, that’s not the right file.

These are coming from an analyzer and there’s nothing you can do about them except lobby here (in another thread) that they get cleaned up. If you do decide to open a new thread on this topic, be sure to include your analyzer versions, found in Administration > Marketplace. Note that SonarJava is the likely culprit here.

Ditto

 
HTH,
Ann


(Norman) #3

Hi Ann,

thanks for your answer.

I did read the requirements docs, but I don’t know for which distribution they are. At least it does not apply for Oracle Linux 7.2 (which is based on Redhat Enterprise Linux 7.2). The doc says to make the change in /etc/limits.d/99-sonarqube.conf, but /etc/limits.d does not exist in Oracle. So I made the change in /etc/security/limits.d/20-nproc.conf, after creating a file /etc/security/limits.d/99-sonarqube.conf did not help.

We also run some Ubuntu servers, and they also do not have a /etc/limits.d folder. Redhat and Ubuntu are two of the main Linux distributions, so I really wonder for which Linux the requirements are applicable.

Regards,
-Norman


(G Ann Campbell) #4

Hi Norman,

I run Ubuntu and made these changes in the other file listed in the docs: /etc/sysctl.conf, and I don’t get the warnings.

###########################
#Req'd for SonarQube
vm.max_map_count=262144
fs.file-max=65536

I’ll ping internally about updating which files the docs target.

Also, such configuration changes made in a file are only going to kick in when the file is (re)read. SonarQube did start in a new session, right?

Ann


(Norman) #8

I also made those settings, not in /etc/sysctl.conf, but in /etc/sysctl.d/99-sonarqube.conf, which is read when /etc/sysctl.conf is loaded. And the proc filesystem also shows the values I entered.

cat /etc/sysctl.d/99-sonarqube.conf

vm.max_map_count=800000
fs.file-max=300000

cat /proc/sys/vm/max_map_count

800000

cat /proc/sys/fs/file-max

300000

However, I do get that “max file descriptors [4096] for elasticsearch process is too low, increase to at least [65536]” message when Sonarqube is started.

We have started using Sonarqube yesterday, and so far, it does not seem to harm anything. I would still like to get on top of that.

Thanks
-Norman


(Eric Hartmann) #9

Hi Norman,

Indeed in newest distributions the location had changed from /etc/limits.d to /etc/security/limits.d/, so your change is correct for RHEL / CentOS / Oracle 7.2. I’ll update the documentation since this is a bit old location.

However, this change is only available for new sessions, so you need to close the session and log in again to take in account the new values (obviously rebooting the server will solve this issue, if you know how to use it, you can use prlimit but it’s more tricky). So I have a couple of questions :

  • what did you do after updating /etc/security/limits.d/20-nproc.conf ?
  • is there any other file setting the limits to lower values ?
  • what is the result of ulimit -n with sonar user ?
  • how are you starting SonarQube (manually or using systemd) ?

Cheers,


(Norman) #10

Hi Eric,

thanks for your answer.

I never heard of prlimit, but I have rebooted the server several times during the installation, and ulimit also shows the right values:

[sonar@host~]$ ulimit -n
65536
[sonar@host~]$ ulimit -u
2048

Before I made the settings in /etc/security/limits.d/20-nproc.conf, I put it in a file /etc/security/limits.d/99-sonarqube.conf, but since that did not help with the warning (although ulimit showed correct values), I moved it into 20-nproc.conf (and removed the other file). The content is (I only added the last two lines):

*       soft    nproc   4096
root    soft    nproc   unlimited
sonar   -       nofile  65536
sonar   -       nproc   2048

I have also tried to change the nproc value for * to 65536, but that also did not remove the warning. I’m not sure though if I rebooted after that change.

As for how I start Sonarqube, I did it manually at first and then added it to systemd. This works fine, the warning is shown in either case.

Thanks
-Norman


(Eric Hartmann) #11

Hi Norman,

That’s really strange, your modifications looks fine to me.
I’ll do a local installation with Oracle Linux 7.2, can you tell me which Java version you are using ?

Cheers,


(Norman) #12

Hi Eric,

I’m using packages from the official repos only, so it is:

java-1.8.0-openjdk-1.8.0.121-0.b13.el7_3.x86_64

at the moment.

-Norman


(Eric Hartmann) #13

Hi Norman,

I think I’ve found the issue systemd is not using the limits declared in /etc/security.
The unit file must contain the limits.

Can you add those lines to your unit file for systemd in the section Service:

LimitNOFILE=65536
LimitNPROC=2048

I’ve checked on a fresh installation and it works on my side (update of your 20-nproc.conf when launching SonarQube manually, and set the limit in the unit file).

Cheers,

Eric


(G Ann Campbell) #14

Hi Eric,

Is this something we should update the docs for?

Ann


(Eric Hartmann) #15

Hi @ganncamp,

I’ve already updated the documentation site :wink:

Cheers,


(Norman) #16

Yes, this also worked on my box. No more warnings in the es.log when starting the service.

Great job, Eric.

Thanks
-Norman