On Wed, Jun 12, 2019 at 7:57 PM Hire, Shannon [US] (MS) < [email protected]> 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
