Re: SonarQube Service Help

[Mantas Mikulėnas <grawity@xxxxxxxxx>]

On Wed, Jun 12, 2019 at 7:57 PM Hire, Shannon [US] (MS) <Shannon.Hire@xxxxxxx> wrote:

Hi,

 

I’m not sure if this is the right place to ask for help, but my system log directed me here.

It varies... The `journalctl -x` output is a bit misleading, in that the message was *shown by* systemd, but quite often has nothing to do with the actual reason the service crashed.

 

 

So I currently have SonarQube set up on a Linux CentOS VM. Yesterday I was able to start up SonarQube just fine, but today I am having issues and am unsure why.

 

Here is the status output:

 

● sonar.service - SonarQube

   Loaded: loaded (/etc/systemd/system/sonar.service; enabled; vendor preset: disabled)

   Active: failed (Result: start-limit) since Wed 2019-06-12 11:12:49 CDT; 3min 21s ago

  Process: 25886 ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh --debug start (code=exited, status=1/FAILURE)

Main PID: 22198 (code=exited, status=0/SUCCESS)

 

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: Failed to start SonarQube.

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: Unit sonar.service entered failed state.

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: sonar.service failed.

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: start request repeated too quickly for sonar.service

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: Failed to start SonarQube.

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: Unit sonar.service entered failed state.

Jun 12 11:12:49 wx-bld07.ms.northgrum.com systemd[1]: sonar.service failed.

Does the service write its logs anywhere else (e.g. directly to /var/log)?

 

[Service]

Type=forking

 

ExecStart=/opt/sonarqube/bin/linux-x86-64/sonar.sh --debug start

Does the script use `su`, `setsid`, `start-stop-daemon`, etc? Can you start the daemon without using sonar.sh at all? What does the --debug option mean for this script?

With Type=forking, when the initial ExecStart process (i.e. the shellscript) exits, the service is "started" and whatever child process is left over gets marked as the service's main process. If *that* process then exits, that counts as the whole service stopping. So in other words, the initial process should have as few layers of forking/backgrounding/daemonization as possible.

--

Mantas Mikulėnas

_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel