ZWE1SV Remains Up even with "Unable to start embedded Tomcat server"

[dkelosky]

I get a startup error Caused by: org.springframework.boot.web.server.WebServerException: Unable to start embedded Tomcat server which followed a message ZWEAM510E Invalid key alias 'localhost'.

I needed to fix my zowe.yaml for the proper alias name; however, I noticed that the STC, ZWE1SV remains active even while services fail to start. Should Zowe services detect this scenario and shutdown automatically with a non-zero return code?

[balhar-jakub]

Is the ZWE1SV general started task for the whole Zowe server, or is it a specific service? Also is the service being restarted? Because if yes, we already have somewhere issue to make sure zowe launcher doesn't restart failed services in certain cases that are unrecoverable.

[dkelosky]

Is the ZWE1SV general started task for the whole Zowe server

Yes. In my case though, I'm only starting API ML related services, e.g. discovery, gateway, catalog, and ZAAS I believe. Since this startup failure meant that nothing in the Zowe STC was usable, I expected everything to shutdown with an error.

[balhar-jakub]

The answer is yes as API ML squad we agree that in this situation the Zowe should stop altogether.

There is already a linked case in the Zowe Launcher - zowe/launcher#95

And other issue touching the problem in API Layer repository - zowe/api-layer#3518

With this stated the issue is related primarily to the Launcher and so I would expand on the issue above or move the issue there.

[1000TurquoisePogs]

In order for the launcher to know to not restart a failed service, there needs to be some way for it to tell the difference between a normal and abnormal end of process.

The launcher can read stdout.
Can you propose a type of message that when the launcher sees it, it knows not to do a restart on exit?
For example, if a process logs "ZWEL000E" and waits a few milliseconds before exiting? I think a moment is needed for the launcher to see the message and register the intent.

As for case #95, this is not caused by launcher as far as I can tell. Since v3.0 it's become easier for me to end up with a gateway that will not shut down unless I issue SIGKILL even when not using the launcher at all (zwe internal start).
I'm unsure of a launcher-specific solution to #95. SIGKILL isn't a real solution in that it has a tendency to not clean up the listening port causing it to be unavailable at restart.
In v2 days there was a trick by which if you saw a gateway hang and were able to kill the listening socket through some system command, the gateway would gracefully stop. I guess the launcher could do that if it's still true to this day. Better would be to get clear reproduction steps and file a bug report.