Partial logs entry:
2020.08.13 22:31:15 INFO app[o.s.a.SchedulerImpl] Stopping SonarQube
2020.08.13 22:31:16 INFO ce[o.s.p.ProcessEntryPoint] Gracefully stopping process
2020.08.13 22:31:17 INFO ce[o.s.ce.app.CeServer] Compute Engine is stopping…
2020.08.13 22:31:18 INFO ce[o.s.c.t.CeProcessingSchedulerImpl] Gracefully stopping workers…
2020.08.13 22:31:18 INFO ce[o.s.ce.app.CeServer] Compute Engine is stopped
2020.08.13 22:31:19 INFO app[o.s.a.SchedulerImpl] Process[ce] is stopped
2020.08.13 22:31:19 INFO web[o.s.p.ProcessEntryPoint] Gracefully stopping process
2020.08.13 22:31:20 INFO web[o.s.s.n.NotificationDaemon] Notification service stopped
Note that there is no error being showed within the log file before the log entry above
this log indicates that someone (or something) send a stop signal (SIGTERM) to this container so sonarqube shut down gracefully. sadly the bundled elasticsearch is sometimes not stopped in time which results in:
nothing to worry about and sadly nothing we can do about (see elastics statement in this issue)
there could be indicators within dmesg or the system log. I also found a network related bug on centos that could be the reason that the network connection in between the database and sonarqube is disrupted, resulting in a shutdown of sonarqube. But i think it has to be something else as there would be a log entry about that