Working Systemd service script

SonarQube
1

SonarQube 7.7 Community edition, Postgresql 10 on Red Hat Enterprise Linux 7.6

The systemd script described on Operating the Server | SonarQube Docs does not take advantage of the Java options defined in the sonar.properties file nor does it take advantage of the start and stop start the server. And when used with sonar.sh does not work.

Here is one that works:

[Unit]
Description=SonarQube service
After=network.target network-online.target
Wants=network-online.target

[Service]
#Type=simple
Type=forking
User=sonar
Group=sonar
#PermissionsStartOnly=true
ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh start
ExecStop=/opt/sonarqube/bin/linux-x86-64/sonar.sh stop
ExecReload=/opt/sonarqube/bin/linux-x86-64/sonar.sh restart
PIDFile=/opt/sonarqube/bin/linux-x86-64/./SonarQube.pid
LimitNOFILE=65536
LimitNPROC=8192
LimitMEMLOCK=262144

#TimeoutStartSec=5
#Restart=always

[Install]
WantedBy=multi-user.target

The TimeoutStartSec could probably be re-added but the process seems to take more than 5 seconds to start. Once that is set, Restart could probably also be restored.

I should give some attribution to the GitHub user wichtounet since that user’s gist was the start of my own - systemd-unit-files/sonar.service at master · wichtounet/systemd-unit-files · GitHub

2

Hi @zielot,

Can you explain why the script does not take advantage of Java options ?
Because this script does start the web and CE with the correct JVM options.
For the service, which advantages do you have while using sonar.sh ?

About :

Do you mean that updating ExecStart with sonar.sh without changing the the Type is not working ? Indeed you have to use forking mode in order to use sonar.sh

sonar.sh is just a wrapper with a third-tier dependency which is not needed while using sonar-application-xxx.jar and using the jar file, looks more convenient.

Cheers,

3

Hi @Eric_Hartmann,

When I wrote “the script does not take advantage of Java options” I was referring to the CE and Web JVM options that are defined in conf/sonar.properties and used by the sonar.sh. It is not clear to me how the these properties (or other properties) would get picked up given your statement that the “correct” ones are used so assumed that the reference systemd sonar.service script did not use them.

Yes, when I wrote that using the provided sonar.service script with the sonar.sh script I was referring to the fact that updating ExecStart with sonar.sh without changing the the Type was not working without specifying forking mode.

So even with your helpful clarifications it seems to me that it is more consistent to specify one startup script with clear configuration and dependencies rather than defining a new one for each startup method. On the other hand, if the sonar.service script had been provided for me with the installation package (and worked) I probably would not have given it a second thought.

What are the negative implications of using the wrapper called by sonar.sh in a systemd service definition that you mention?

Regards,
Justin