Re: Probelm with shutdown script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/29/20 20:28, Mark Thomas wrote: > On 28/08/2020 20:54, Christopher Schultz wrote: >> Calder, >> >> On 8/27/20 18:23, calder wrote: >>> On Thu, Aug 27, 2020, 16:16 Christopher Schultz < >>> ch...@christopherschultz.net> wrote: >> >>> [ snip ] >> >>> If you want to *kill* the application and it won't shut down >>> on its own, SIGKILL is the answer. But that's not a great way to shut down an application /in general/ because the application might want/need to do something convenient on shutdown (flush caches, save state, etc.). >> >> >> >>> SIGTERM is the polite way to ask an application to shut down. A >>> JVM will respond to this signal. (SIGHUP will also initiate a >>> shut down, but TERM is preferred). Using TERM will cause the >>> shutdown hooks to initiate. >> >>> As Chris states, SIGKILL is a last resort (hooks are not >>> called). >> >> If you send a SIGTERM to a Tomcat process, your application's >> ServletContextListeners and stuff like that will not run. > > Yes it will. Tomcat will shutdown cleanly (after cleanly shutting > down any running web applications). Oh really? How does that work? Oh, right. A shutdown-hook. :) >> Sure, you can register shutdown-hook, but ... eew. That's like, >> AWFUL, man. > > You mean like Tomcat already does? Applications don't/shouldn't do > this because Tomcat has already done so. Exactly. Shutdown hooks from web applications should never be done. I don't think of Tomcat as an "application". It does make sense for containers to register such things. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NFU0ACgkQHPApP6U8 pFjL3g/8DDOQDPdx+tuPw1ecd98u5YEuotkZXfFxl9u266up9fmBG8XubDRS85bX 60etRvJCmcH5lXCsBCmmnrDyK/KaxPDpM4OOMwnuEIfQOrQDN4uA3pz5FncAL1sO VC3XJg9u341M2CHyw4yC0uqshSSWXXAhum3VoKBR82iHMQmlxu8bStwep1V39irS rb4hqUIMi2puIXb8TJXln4oUSh+dL37Y5ksSc+0bk4+xiJF4KwevRbdp8AzoSFMO H85W6Oafzj6R6mWbs2OL09PCxC05A5UqR5BlfspJWTHwT3hq8NeVIlDBWX3tzK8n L5M8gKwjL0UdXmINwJbsjPdesDrQdVwjvqZrIvYFCKl0SIaG2q0vRr2Qi+RmaNIC zG7+U1SR1WQ8nVTnynvo3xP36eXnmyLNFG/4sXvxG30VpiLatpoCMZnNfb7ChtMC waX68CREil12sNgLXP+GGfbWFhxnnBrMoaGI/6/+9Ed8DBwGwGRiOcbN0mxgAOQy 09dpMXsx4bgUTfmYd/GI2bWQW5XoJfz9Z3xzq9UvMsd1RaHSHIFRwxRvQYkw0HZm eKhUYq198FrxR9l+IJirKsZBwgIqYUFHc1p1pdCF14R7l2w94ofHPAEL/Q7Nj1ce SdYsNq73dfaaW+fWwj8t3MLuDjqtQv+gwWQwV+0KzjjZ5wvCIHM= =zfLt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
On 28/08/2020 20:54, Christopher Schultz wrote: > Calder, > > On 8/27/20 18:23, calder wrote: >> On Thu, Aug 27, 2020, 16:16 Christopher Schultz < >> ch...@christopherschultz.net> wrote: > >> [ snip ] > >> If you want to *kill* the application and it won't shut down on >> its >>> own, SIGKILL is the answer. But that's not a great way to shut >>> down an application /in general/ because the application might >>> want/need to do something convenient on shutdown (flush caches, >>> save state, etc.). > > > >> SIGTERM is the polite way to ask an application to shut down. A JVM >> will respond to this signal. (SIGHUP will also initiate a shut >> down, but TERM is preferred). Using TERM will cause the shutdown >> hooks to initiate. > >> As Chris states, SIGKILL is a last resort (hooks are not called). > > If you send a SIGTERM to a Tomcat process, your application's > ServletContextListeners and stuff like that will not run. Yes it will. Tomcat will shutdown cleanly (after cleanly shutting down any running web applications). > Sure, you > can register shutdown-hook, but ... eew. That's like, AWFUL, man. You mean like Tomcat already does? Applications don't/shouldn't do this because Tomcat has already done so. Mark > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Calder, On 8/27/20 18:23, calder wrote: > On Thu, Aug 27, 2020, 16:16 Christopher Schultz < > ch...@christopherschultz.net> wrote: > > [ snip ] > > If you want to *kill* the application and it won't shut down on > its >> own, SIGKILL is the answer. But that's not a great way to shut >> down an application /in general/ because the application might >> want/need to do something convenient on shutdown (flush caches, >> save state, etc.). > > > > SIGTERM is the polite way to ask an application to shut down. A JVM > will respond to this signal. (SIGHUP will also initiate a shut > down, but TERM is preferred). Using TERM will cause the shutdown > hooks to initiate. > > As Chris states, SIGKILL is a last resort (hooks are not called). If you send a SIGTERM to a Tomcat process, your application's ServletContextListeners and stuff like that will not run. Sure, you can register shutdown-hook, but ... eew. That's like, AWFUL, man. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9JYPgACgkQHPApP6U8 pFjIxhAAiqinCiRXer/BSW51oMvzCsGPqSXkNCLodYSBgC0FICBco5ZQBcCsYzIK AOKM4v8vwnjR4uF9Sb1wETj9OqkgLUXseb2w6XKzOXA1xE6KK0m5UM2JMnY+XBeA KQtUgzeRlKDtYZ801q2FLvOTSqFgF0NirUu9fQhR96fSWDFIH3uimqLb00WeUtfT mlxHZufuJcwp+cZVW5CXH8qzUvDgAMCsnf7lV70Y3e1oEUuUE04PdtWfAyjoIsN6 3tguqfgAbSXfA6S4b+Q7hsnzu2ncYnJzvl6nj0Lp2+fMacl6wL5DwFIkHJBbru4Q Fv0wMSFDwVx1nNIR+Mr6JOnxtnmERiDVDDdQE+FAGDuQFysrODJjmcmC1nb23/Db kQGTBoIXk7W6Rn1n3hT13WAJmlQIrgDETxaswEI3nON7JC5nmPG7G28aI/66mMLb ozyrmkrFHRd1oeXasgkTGZa3mvR8kwy85IqmGt3QNbWBa68VPZRQaUp96lkj1qiI PVDo5CQAJxfTOnq5t7PZixq8uc1zIBu3besOP7vgVz2TgmXHF1Zrk/BaUoZYy+5H VFTog7JjhIZnUBNp7uoq0SsCXfXvrC0dCGkVF5rLE3nxtjkas7LlhmZf4E4QD5zJ jdI9Mt+keR0CHOyaeGK9P13N/S+EN2qTuwPdoCsDv66ulZtpwds= =pzzj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
On Thu, Aug 27, 2020, 16:16 Christopher Schultz < ch...@christopherschultz.net> wrote: [ snip ] If you want to *kill* the application and it won't shut down on its > own, SIGKILL is the answer. But that's not a great way to shut down an > application /in general/ because the application might want/need to do > something convenient on shutdown (flush caches, save state, etc.). SIGTERM is the polite way to ask an application to shut down. A JVM will respond to this signal. (SIGHUP will also initiate a shut down, but TERM is preferred). Using TERM will cause the shutdown hooks to initiate. As Chris states, SIGKILL is a last resort (hooks are not called). [ snip ]
Re: Probelm with shutdown script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roger, On 8/27/20 14:43, Roger Marquis wrote: > Mark Thomas wrote: >> Those are all application issues. The application should shut >> itself down cleanly. Tomcat is complaining because it hasn't. > > I don't know Mark, most Java/Tomcat engineers expect an application > to shutdown when it's os/container/shell/parent shuts-down. Can > you help us understand why Tomcat is different in this respect than > say Apache httpd? Along with Mark's reply, there is also the fact that httpd doesn't really run "applications" per se. If you are using something like mod_php or CGI, then that's all ephemeral: once the request is done, the child process dies. Or, more specifically, the child process exits and that's what causes the response to be sent to the client. There is little to no notion of cross-request state in httpd. Requesting httpd to stop sends a signal to the primary httpd process which tells all its children to stop. If there is a problem with a child (e.g. it's processing a request, or stuck in some way), the primary process has to decide what to do about it. It may be able to SIGKILL it. Maybe not, depending upon process privileges (though the primary process usually runs as root, so it should be able to do that). For threaded MPMs, the primary or child process can choose what to do about killing the threads that appear stuck. The pthreads library has a pthread_cancel function which requests that the thread be stopped, but it does not guarantee anything. This is similar to Java, except that Java has gone so far as to say "the Thread.stop method should not be used" (because it is not reliable, it causes weirdness in the JVM, etc.). If you want to *kill* the application and it won't shut down on its own, SIGKILL is the answer. But that's not a great way to shut down an application /in general/ because the application might want/need to do something convenient on shutdown (flush caches, save state, etc.). The previous two paragraphs are mostly valid for both httpd AND Tomcat. The reason httpd is often "cleaner" than Tomcat sometimes is, is because of the applications running within Tomcat. httpd is really a web server, and Tomcat is an application container. Could Tomcat be more aggressive about killing applications when they aren't behaving appropriately? Maybe. But then you'd never fix your application, now would you? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9IInAACgkQHPApP6U8 pFi6zw//WBFH087QqzmZbgdQjPxDhZ5f5L9lQmp4VFaw+dOEkP4xNMkGCxWeTq1Z 1nmogFYsZ8vns8z1f8RJ22aDWhdFqCDDHlJkqobR/4d4wiKd0hmjm75s8NH2YeCk 2UwwlStV99n5BNu3/TBTQFyjUv2rhz8cO8tDkztFGS7avXogSm08zeeHgVIC8cWV tiGBe7QVH/PMeanGl+/1IdWQ5PmpmNpGBv5YGJMYfU9Hmul/GeNW55pLJPSxS7ll /8thgxDVK4VudnA6MGELVSht56qlEQtlekMJjSUUvagmT94yTDXd7teOagZL9U79 26EL5tOiSkE4GGPoR/jQa0kj0bNMHMUJsBJRoHDCXxQdJhPLTGZNKZM1yMgAlMnc 6D2/acg9TbO6ia0Q1qpQmh2vWUlMPdp4U8X1uP6RdKKQyyjM5Pzinw/ysktgEBpI lYSI+uz3uG0iJGzqECPaoTpTTtSqdtG68QVqU2Kgv4lHmENNHFWMDKbB3glwqfBN KLw6fCrKGG6XGdQEcgtR8GjyNNpErLcf7PzIqXtwo9bNoQWNhYF/VjjndRJTTL98 IwoEL9qHXs0hhtKHA4x7kir0OARjwXDNwuJGu9LrKX1qOtzNxUAmjckHtLDjb5m8 nWmsz2zzy1rak1t1EPVsFjfOu5kZL+++IQcXja29uZshuiPcWbI= =vc24 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
On 27/08/2020 19:43, Roger Marquis wrote: > Mark Thomas wrote: >> Those are all application issues. The application should shut itself >> down cleanly. Tomcat is complaining because it hasn't. > > I don't know Mark, most Java/Tomcat engineers expect an application to > shutdown when it's os/container/shell/parent shuts-down. Can you help > us understand why Tomcat is different in this respect than say Apache > httpd? Java doesn't provide an API a cleanly stop another thread. If an application starts a non-daemon thread but doesn't stop it there is nothing Tomcat can do to stop that thread and the JVM won't shutdown until the thread stops. Using OS level tools to stop the process is the only option. Hence, applications are responsible to cleaning up the resources they create. For example, if an app starts a thread then the app is also responsible for stopping it. Generally, apps use one or more ServletContextListeners to do this. Along similar lines, failing to clean up resources can also trigger memory leaks. Tomcat will clean those up where it can and log the problems it finds so the application can address them. While such issues are unimportant when shutting Tomcat down entirely, they are much more serious if the web application is being redeployed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
Mark Thomas wrote: Those are all application issues. The application should shut itself down cleanly. Tomcat is complaining because it hasn't. I don't know Mark, most Java/Tomcat engineers expect an application to shutdown when it's os/container/shell/parent shuts-down. Can you help us understand why Tomcat is different in this respect than say Apache httpd? Roger Marquis - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
On 25/08/2020 16:40, ratatouille wrote: > Mark Thomas schrieb am 25.08.20 um 11:31:59 Uhr: > >> On 25/08/2020 11:07, ratatouille wrote: > >>> I am running openmeetings on a CentOS 8 server and start it with startup.sh >>> in the bin-folder. >>> >>> The problem is when I execute shutdown.sh the process still exists after. >>> I have to kill it manually. > >>> I was told these scripts are un-modified scripts of Apache Tomcat >>> 9.0.37, that's why I am asking here for help. >>> >>> Any hint on this? >> >> Take a Java thread dump of the still running process. That should point >> you towards what hasn't shutdown properly. > > I see some warnings and stack traces when I execute shutdown.sh. > For example: Those are all application issues. The application should shut itself down cleanly. Tomcat is complaining because it hasn't. Mark > > 25-Aug-2020 17:31:49.246 WARNUNG [main] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The > web application [openmeetings > ] appears to have started a thread named [nioEventLoopGroup-3-4] but has > failed to stop it. This is very likely to create a memory leak. Stack tr > ace of thread: > java.base@11.0.8/java.lang.Thread.sleep(Native Method) > > io.netty.util.concurrent.SingleThreadEventExecutor.confirmShutdown(SingleThreadEventExecutor.java:790) > io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:525) > > io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) > io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) > > io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) > java.base@11.0.8/java.lang.Thread.run(Thread.java:834) > 25-Aug-2020 17:31:49.280 SCHWERWIEGEND [main] > org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks > The web application [o > penmeetings] created a ThreadLocal with key of type [java.lang.ThreadLocal] > (value [java.lang.ThreadLocal@14a07c8d]) and a value of type [io.nett > y.util.internal.InternalThreadLocalMap] (value > [io.netty.util.internal.InternalThreadLocalMap@6096444e]) but failed to > remove it when the web app > lication was stopped. Threads are going to be renewed over time to try and > avoid a probable memory leak. > 25-Aug-2020 17:31:49.289 INFORMATION [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > ["http-nio-5080"] > 25-Aug-2020 17:31:49.296 INFORMATION [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > ["https-jsse-nio-5443"] > 25-Aug-2020 17:31:49.302 INFORMATION [main] > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler > ["http-nio-5080"] > 25-Aug-2020 17:31:49.305 INFORMATION [main] > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler > ["https-jsse-nio-5443"] > 25-Aug-2020 17:31:50.921 INFORMATION [mysql-cj-abandoned-connection-cleanup] > org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResour > ceLoading Illegal access: this web application instance has been stopped > already. Could not load []. The following stack trace is thrown for debu > gging purposes as well as to attempt to terminate the thread which caused the > illegal access. > java.lang.IllegalStateException: Illegal access: this web application > instance has been stopped already. Could not load []. The following > stack trace is thrown for debugging purposes as well as to attempt to > terminate the thread which caused the illegal access. > at > org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1385) > at > org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1038) > at > com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.checkThreadContextClassLoader(AbandonedConnectionCleanupThread.java:117) > at > com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:84) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > > The output of the shutdown is a lot longer than the above. > > I have no clue about Java and tomcat so I can't do anything about this. > > Andreas > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
The only time I ran into this is when I had conflict on the shutdown port or multiple instances which had a port conflict on the shutdown port. Other than that, I don't know. Possible permissions issues? Pete Helgren www.petesworkshop.com GIAC Secure Software Programmer-Java AWS Certified Cloud Practitioner Twitter - Sys_i_Geek IBM_i_Geek On 8/25/2020 5:07 AM, ratatouille wrote: Hello! I am running openmeetings on a CentOS 8 server and start it with startup.sh in the bin-folder. The problem is when I execute shutdown.sh the process still exists after. I have to kill it manually. # - # Stop script for the CATALINA Server # - # Better OS/400 detection: see Bugzilla 31132 os400=false case "`uname`" in OS400*) os400=true;; esac # resolve links - $0 may be a softlink PRG="$0" while [ -h "$PRG" ] ; do ls=`ls -ld "$PRG"` link=`expr "$ls" : '.*-> \(.*\)$'` if expr "$link" : '/.*' > /dev/null; then PRG="$link" else PRG=`dirname "$PRG"`/"$link" fi done PRGDIR=`dirname "$PRG"` EXECUTABLE=catalina.sh # Check that target executable exists if $os400; then # -x will Only work on the os400 if the files are: # 1. owned by the user # 2. owned by the PRIMARY group of the user # this will not work if the user belongs in secondary groups eval else if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then echo "Cannot find $PRGDIR/$EXECUTABLE" echo "The file is absent or does not have execute permission" echo "This file is needed to run this program" exit 1 fi fi exec "$PRGDIR"/"$EXECUTABLE" stop "$@" I was told these scripts are un-modified scripts of Apache Tomcat 9.0.37, that's why I am asking here for help. Any hint on this? Andreas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
Mark Thomas schrieb am 25.08.20 um 11:31:59 Uhr: > On 25/08/2020 11:07, ratatouille wrote: > > I am running openmeetings on a CentOS 8 server and start it with startup.sh > > in the bin-folder. > > > > The problem is when I execute shutdown.sh the process still exists after. > > I have to kill it manually. > > I was told these scripts are un-modified scripts of Apache Tomcat > > 9.0.37, that's why I am asking here for help. > > > > Any hint on this? > > Take a Java thread dump of the still running process. That should point > you towards what hasn't shutdown properly. I see some warnings and stack traces when I execute shutdown.sh. For example: 25-Aug-2020 17:31:49.246 WARNUNG [main] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [openmeetings ] appears to have started a thread named [nioEventLoopGroup-3-4] but has failed to stop it. This is very likely to create a memory leak. Stack tr ace of thread: java.base@11.0.8/java.lang.Thread.sleep(Native Method) io.netty.util.concurrent.SingleThreadEventExecutor.confirmShutdown(SingleThreadEventExecutor.java:790) io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:525) io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) java.base@11.0.8/java.lang.Thread.run(Thread.java:834) 25-Aug-2020 17:31:49.280 SCHWERWIEGEND [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [o penmeetings] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@14a07c8d]) and a value of type [io.nett y.util.internal.InternalThreadLocalMap] (value [io.netty.util.internal.InternalThreadLocalMap@6096444e]) but failed to remove it when the web app lication was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. 25-Aug-2020 17:31:49.289 INFORMATION [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-5080"] 25-Aug-2020 17:31:49.296 INFORMATION [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["https-jsse-nio-5443"] 25-Aug-2020 17:31:49.302 INFORMATION [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-nio-5080"] 25-Aug-2020 17:31:49.305 INFORMATION [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["https-jsse-nio-5443"] 25-Aug-2020 17:31:50.921 INFORMATION [mysql-cj-abandoned-connection-cleanup] org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResour ceLoading Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debu gging purposes as well as to attempt to terminate the thread which caused the illegal access. java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load []. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access. at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1385) at org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1038) at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.checkThreadContextClassLoader(AbandonedConnectionCleanupThread.java:117) at com.mysql.cj.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:84) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) The output of the shutdown is a lot longer than the above. I have no clue about Java and tomcat so I can't do anything about this. Andreas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Probelm with shutdown script
On 25/08/2020 11:07, ratatouille wrote: > Hello! > > I am running openmeetings on a CentOS 8 server and start it with startup.sh > in the bin-folder. > > The problem is when I execute shutdown.sh the process still exists after. > I have to kill it manually. > > # > - > # Stop script for the CATALINA Server > # > - > > # Better OS/400 detection: see Bugzilla 31132 > os400=false > case "`uname`" in > OS400*) os400=true;; > esac > > # resolve links - $0 may be a softlink > PRG="$0" > > while [ -h "$PRG" ] ; do > ls=`ls -ld "$PRG"` > link=`expr "$ls" : '.*-> \(.*\)$'` > if expr "$link" : '/.*' > /dev/null; then > PRG="$link" > else > PRG=`dirname "$PRG"`/"$link" > fi > done > > PRGDIR=`dirname "$PRG"` > EXECUTABLE=catalina.sh > > # Check that target executable exists > if $os400; then > # -x will Only work on the os400 if the files are: > # 1. owned by the user > # 2. owned by the PRIMARY group of the user > # this will not work if the user belongs in secondary groups > eval > else > if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then > echo "Cannot find $PRGDIR/$EXECUTABLE" > echo "The file is absent or does not have execute permission" > echo "This file is needed to run this program" > exit 1 > fi > fi > > exec "$PRGDIR"/"$EXECUTABLE" stop "$@" > > I was told these scripts are un-modified scripts of Apache Tomcat > 9.0.37, that's why I am asking here for help. > > Any hint on this? Take a Java thread dump of the still running process. That should point you towards what hasn't shutdown properly. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Probelm with shutdown script
Hello! I am running openmeetings on a CentOS 8 server and start it with startup.sh in the bin-folder. The problem is when I execute shutdown.sh the process still exists after. I have to kill it manually. # - # Stop script for the CATALINA Server # - # Better OS/400 detection: see Bugzilla 31132 os400=false case "`uname`" in OS400*) os400=true;; esac # resolve links - $0 may be a softlink PRG="$0" while [ -h "$PRG" ] ; do ls=`ls -ld "$PRG"` link=`expr "$ls" : '.*-> \(.*\)$'` if expr "$link" : '/.*' > /dev/null; then PRG="$link" else PRG=`dirname "$PRG"`/"$link" fi done PRGDIR=`dirname "$PRG"` EXECUTABLE=catalina.sh # Check that target executable exists if $os400; then # -x will Only work on the os400 if the files are: # 1. owned by the user # 2. owned by the PRIMARY group of the user # this will not work if the user belongs in secondary groups eval else if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then echo "Cannot find $PRGDIR/$EXECUTABLE" echo "The file is absent or does not have execute permission" echo "This file is needed to run this program" exit 1 fi fi exec "$PRGDIR"/"$EXECUTABLE" stop "$@" I was told these scripts are un-modified scripts of Apache Tomcat 9.0.37, that's why I am asking here for help. Any hint on this? Andreas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
