https://issues.apache.org/bugzilla/show_bug.cgi?id=55743
--- Comment #5 from Konstantin Kolinko <knst.koli...@gmail.com> --- (In reply to Felix Becker from comment #2) > > But I'm wondering why that is implemented in this way because a normal > SIGTERM causes a graceful shutdown - is there any reason why the catalina.sh > doesn't send this SIGTERM? > 1. Apache Commons Daemon stops Tomcat from the "inside". It has direct access to JVM that runs Tomcat. Thus no need for an external connection and that is the reason why the port may be disabled. 2. Using SIGTERM is not guaranteed to be as clear as proper shutdown command. There may be several shutdown hooks in the JVM. They all will be started at the same time and may suffer from a race condition. E.g. if Log4J had such a hook (very likely, but I do not know whether it has one) then it might be shut down before a web application that uses it. (In reply to Mark Thomas from comment #4) > It should be possible to check a return value from the call to stop(). If > that is non-zero and we have a pid, try that next? +1. Catalina.stopServer() already has the necessary code and exits with return code of "1". I was thinking whether there should be a separate return code for this use case. IMO, we do not need one. If "stopServer()" failed then Tomcat does not know that we tried to stop it and it is logical to try SIGTERM next. One good thing is that with this we can stop Tomcats that are in the process of starting up and have not opened the shutdown port yet. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
