Probelm with shutdown script

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Probelm with shutdown script

ratatouille
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

markt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

ratatouille
Mark Thomas <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

Pete Helgren
In reply to this post by ratatouille
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

markt
In reply to this post by ratatouille
On 25/08/2020 16:40, ratatouille wrote:

> Mark Thomas <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

Roger Marquis
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

markt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

Christopher Schultz-2
In reply to this post by Roger Marquis
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

calder
On Thu, Aug 27, 2020, 16:16 Christopher Schultz <
[hidden email]> 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 ]
Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

Christopher Schultz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Calder,

On 8/27/20 18:23, calder wrote:

> On Thu, Aug 27, 2020, 16:16 Christopher Schultz <
> [hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

markt
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 <
>> [hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Probelm with shutdown script

Christopher Schultz-2
-----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 <
>>> [hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]