SonarQube 7.4 on Linux: PID file vanishes within few seconds after wrapper service starts, even though SonarQube service is running

sonarqube
(Kishan Parekh) #1

I am using SonarQube 7.4 Community Edition on RHEL 7.6, and have followed all requirements as per documentation on https://docs.sonarqube.org/7.4/

How to reproduce

./bin/linux-x86-64/sonar.sh start shows that SonarQube is running, and it is indeed running by subsequently connecting to port 9000 through browser.

However, even while SonarQube service is running, PID file (./temp/SonarQube.pid) disappears within few seconds, just after “Started SonarQube” message appears, and before shell script ends. I have verified this by adding debug messages within shell script.

Due to disappearance of a PID file, ./bin/linux-x86-64/sonar.sh stop and ./bin/linux-x86-64/sonar.sh status which checks for presence of PID file complains that SonarQube is not running.

Though not a foolproof method, I am considering a workaround that “start()” function of sonar.sh will create a PID file few seconds after wrapper is run, and PID file vanishes.

Do you face similar issues on Linux system, and if yes, any suggestions to resolve this issue?

(G Ann Campbell) #2

Hi,

I suspect the causality is the other way around. SonarQube starts 4 processes, each of which has its own log. One of them is failing to start up correctly and that causes the whole thing to shut back down. You should find the real problem in one of the logs.

 
Ann

(Kishan Parekh) #3

@Ann, thanks for this hint. I will thoroughly go through logs line by line after purging existing logs.

However, few observations by running ps auxwww | grep '^sonar, netstat -lntp and tailing of 4 log files: I see all 4 processes are running, and I could see that none of the 4 log files described any error at the end. I also successfully performed SonarScan on one of the open-source project based on MEAN stack.

ElasticSearch is up and listening on port 9001

es.log: 2018.12.07 09:34:07 INFO es[][o.e.g.GatewayService] recovered [8] indices into cluster_state 2018.12.07 09:34:09 INFO es[][o.e.c.r.a.AllocationService] Cluster health status changed from [RED] to [GREEN] (reason: [shards started [[metadatas][0]] ...]).

sonar.log: 2018.12.07 09:34:09 INFO app[][o.s.a.SchedulerImpl] Process[es] is up

CE server is up and listening on port 39272

sonar.log: 2018.12.07 09:34:26 INFO app[][o.s.a.SchedulerImpl] Process[ce] is up

Sonar Server is up and listening on port 32000

sonar.log: 2018.12.07 09:34:26 INFO app[][o.s.a.SchedulerImpl] SonarQube is up

Web server is up and listening on port 9000

web.log: 2018.12.07 09:34:21 INFO web[][o.s.s.p.p.PlatformLevelStartup] Running Community Edition 2018.12.07 09:34:21 INFO web[][o.s.s.p.Platform] WebServer is operational

sonar.log: 2018.12.07 09:34:21 INFO app[][o.s.a.SchedulerImpl] Process[web] is up

So far, I have put a work-around by creating a file within sonar.sh. None the less, I will recheck each log file thoroughly and update my findings.

(G Ann Campbell) #4

Hi,

So… if there are no errors in your logs, and they would be very obvious and the last thing in the relevant file, then I would look for some external process interfering with the pid.

 
Ann