Simon,

On 11/30/21 08:21, Simon Matter wrote:
I'm running an application on Tomcat 9.0.55 on x86_64 Linux with OpenJDK
JRE-11.0.13+8 and have problems shutting down Tomcat in certain ways.

When I shutdown Tomcat via 'catalina.sh stop', it shuts down mostly (most
threads are gone) but send a thread dump to catalina.out and is later
killer by an OS signal.

This should only happen if you have CATALINA_PID defined. Are you indeed defining that environment variable?

catalina.sh has this code in it, which is probably what you are seeing:

echo "To aid diagnostics a thread dump has been written to standard out."
          kill -3 `cat "$CATALINA_PID"`

When shutting down Tomcat via the shutdown listener on port 8005, it also
shuts down mostly but without the thread dump in catalina.out. Sending
SIGTERM later to the still running java process terminates it.

Right: when you manually connect to the shutdown port and send "SHUTDOWN" (or whatever), it asks Tomcat to shut down but doesn't send a signal. You have to do that manually, too.

So both methods somehow terminate Tomcat partly but not completely.

You have one or two of the following issues:

1. You have a non-daemon thread running
2. You have an unusually long shutdown process that just takes "too long"

The good news is that the thread-dup can answer that question: what's in the thread dump that is generated when you run "catalina.sh stop"?

When simply sending SIGTERM on the OS level, Tomcat shuts down cleanly and
terminates without issues.

One thing in common is that I always see these messages while shutting down:

30-Nov-2021 13:59:36.985 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class
[sun.rmi.registry.RegistryImpl_Stub] and value
[RegistryImpl_Stub[UnicastRef [liveRef:
[endpoint:[157.161.91.47:2071](local),objID:[0:0:0, 0]]]]]. This RMI
Target has been forcibly removed to prevent a memory leak.
30-Nov-2021 13:59:36.987 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class [com.sun.proxy.$Proxy51] and value
[Proxy[ShopdbCacheSynchronizer,RemoteObjectInvocationHandler[UnicastRef
[liveRef:
[endpoint:[157.161.91.47:1096](local),objID:[-6f4b2f9d:17d70eb1ef4:-7ffd,
-4005526521234186948]]]]]]. This RMI Target has been forcibly removed to
prevent a memory leak.
30-Nov-2021 13:59:36.987 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class
[sun.rmi.registry.RegistryImpl_Stub] and value
[RegistryImpl_Stub[UnicastRef [liveRef:
[endpoint:[157.161.91.47:1096](local),objID:[0:0:0, 0]]]]]. This RMI
Target has been forcibly removed to prevent a memory leak.

Why do the three methods to shutdown Tomcat differ and how can I make
'catalina.sh stop' or the shutdown listener work the same way like sending
the OS signal.

What's the difference? You don't want the thread dump in your catalina.out? That's supposed to be helpful in debugging why your shutdown isn't clean. It sounds like you are saying "help me with my unclean shutdown; please get rid of the debugging information that is trying to help me!".

I've tried, beside a lot of other things, to set
skipMemoryLeakChecksOnJvmShutdown="true" in context.xml but it seems to
change nothing at all.

Tomcat will never kill your non-daemon thread(s) from inside the VM. Since you are using a CATALINA_PID environment variable (and, therefore, a pid-file), the shutdown process is sending the TERM signal. It's also possibly sending a KILL signal, depending on whether or not the TERM worked and if -force was supplied on the command-line.

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to