Discussion:
Lack of shutdown port (port="-1") behavior does not appear to match documentation
Steven Schlansker
2011-03-26 00:21:10 UTC
Permalink
Hi everyone,
I'm running Tomcat 6.0.32 on Linux and am encountering a pretty confusing mismatch between documentation and reality. Hoping you can verify that this is a problem or point out where I'm doing things wrong.

We are running multiple tomcats on the same server (to provide additional levels of isolation between different webapps) but the shutdown port is inconvenient to manage when you are dealing with flexible deploys. In particular the different tomcats will attempt to bind to the same loopback port, causing problems.

The documentation states:

port

The TCP/IP port number on which this server waits for a shutdown command. This connection must be initiated from the same server computer that is running this instance of Tomcat. Set to -1 to disable the shutdown port. Note: Disabling the shutdown port will prevent shutdown.bat and catalina.bat from stopping the Tomcat process on Windows operating systems. Operating systems that use the *.sh scripts will not be affected by disabling the shutdown port.


However, the shell scripts do not appear to actually shut down the Tomcat correctly. They invoke Bootstrap stop, which gives up thusly:

// Stop the existing server
s = getServer();
try {
if (s.getPort()>0) {
// <snip> do that shutdown thing
} else {
log.error(sm.getString("catalina.stopServer"));
System.exit(1);
}

(Catalina.java:418)

and I can confirm seeing the "catalina.stopServer" message in my logs:

ERROR <> 2011-03-25 15:34:08,827 main org.apache.catalina.startup.Catalina No shutdown port configured in server.xml. Please shut down server through OS signal. Server not shut down by external JVM.

The end result is that shutdown.sh hangs for the "timeout" period and then sends a kill -9 to the tomcat. Not the most graceful shutdown!

I would expect that the script would attempt to send a kill -TERM to tomcat if Bootstrap shutdown fails, but it does not appear to do that.


Thoughts? Is this a known issue?

Thanks much for any guidance,
Steven Schlansker
Konstantin Kolinko
2011-03-27 21:06:09 UTC
Permalink
Post by Steven Schlansker
Hi everyone,
I'm running Tomcat 6.0.32 on Linux and am encountering a pretty confusing mismatch between documentation and reality.  Hoping you can verify that this is a problem or point out where I'm doing things wrong.
We are running multiple tomcats on the same server (to provide additional levels of isolation between different webapps) but the shutdown port is inconvenient to manage when you are dealing with flexible deploys.  In particular the different tomcats will attempt to bind to the same loopback port, causing problems.
port
The TCP/IP port number on which this server waits for a shutdown command. This connection must be initiated from the same server computer that is running this instance of Tomcat. Set to -1 to disable the shutdown port. Note: Disabling the shutdown port will prevent shutdown.bat and catalina.bat from stopping the Tomcat process on Windows operating systems. Operating systems that use the *.sh scripts will not be affected by disabling the shutdown port.
(...)
The end result is that shutdown.sh hangs for the "timeout" period and then sends a kill -9 to the tomcat.  Not the most graceful shutdown!
kill -9 is sent only of you add "-force" to the shutdown command. It
does not do so by default.
Post by Steven Schlansker
I would expect that the script would attempt to send a kill -TERM to tomcat if Bootstrap shutdown fails, but it does not appear to do that.
The script does not know why shutdown fails. It does not read
server.xml to note this configuration, nor it parses the log messages
(which might be i18n'ed).

It might be a bad idea to use System.exit() in Bootstrap to explicitly
return a non-zero result code, because "Bootstrap stop" might be
called from jsvc or in another embedded scenarios and thus it should
not forcibly terminate the JVM.


If you have ideas/patch on how it can be implemented, please file an
enhancement request.

You are right that the documentation was incorrect there. I updated it,
http://svn.apache.org/viewvc?rev=1086036&view=rev


Best regards,
Konstantin Kolinko

Loading...