I am using SonarQube 7.4 Community Edition on RHEL 7.6, and have followed all requirements as per documentation on Documentation
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?
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, 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.
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.