You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by James Lampert <ja...@touchtonecorp.com> on 2012/06/19 22:58:22 UTC
Tomcat shutdown.sh troubleshooting on AS/400
In my experience, Tomcat's "shutdown.sh" has never worked reliably on
AS/400, and I don't know why, or even understand enough about how it
works (or enough about shell scripts) to troubleshoot it.
Here's the script. I can tell that it eventually transfers control to
catalina.sh (which is also what launches Tomcat), but that's about all I
can make out without help.
> #!/bin/sh
>
> # Licensed to the Apache Software Foundation (ASF) under one or more
> # contributor license agreements. See the NOTICE file distributed with
> # this work for additional information regarding copyright ownership.
> # The ASF licenses this file to You under the Apache License, Version 2.0
> # (the "License"); you may not use this file except in compliance with
> # the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing, software
> # distributed under the License is distributed on an "AS IS" BASIS,
> # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> # See the License for the specific language governing permissions and
> # limitations under the License.
>
> # -----------------------------------------------------------------------------
> # Stop script for the CATALINA Server
> #
> # $Id: shutdown.sh 1202062 2011-11-15 06:50:02Z mturk $
> # -----------------------------------------------------------------------------
> # 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 "$@"
Can somebody shed some light on it?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat shutdown.sh troubleshooting on AS/400
Posted by Tim Watts <ti...@cliftonfarm.org>.
On Wed, 2012-06-20 at 19:19 -0400, David Kerber wrote:
> On 6/19/2012 8:07 PM, André Warnier wrote:
> > James Lampert wrote:
> >> . . . and when I looked back at the box I was testing, Tomcat *had*
> >> finally shut down. And when I ran both the start and stop scripts
> >> this time, the stop script worked perfectly (and promptly).
> >>
> >> Weird. Why would the shutdown take so long as to give the impression
> >> it had failed entirely, then eventually work, then later work promptly?
> >>
> >
> > 1) Gremlins. You need to exorcise your datacenter.
> > or
> > 2) because the first time, Tomcat had been running for a while, so it
> > had a lot of things to shut down nicely and cleanup; while the second
> > time, it had only be running for a much shorter time, and had less to
> > clean up ?
>
> It's not gremlins, it's magic. I see this all the time on windows: it
> shuts down in the time I'm willing to wait for it ~50% of the time. The
> other 50% I end up killing the task.
>
Any time I've seen this it's because some app or library has carelessly
started non-daemon threads that are still spinning. Everything Tomcat
can shutdown has shutdown. You could always try 'catalina.sh stop
-force'.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Tomcat shutdown.sh troubleshooting on AS/400
Posted by David Kerber <dc...@verizon.net>.
On 6/19/2012 8:07 PM, André Warnier wrote:
> James Lampert wrote:
>> . . . and when I looked back at the box I was testing, Tomcat *had*
>> finally shut down. And when I ran both the start and stop scripts
>> this time, the stop script worked perfectly (and promptly).
>>
>> Weird. Why would the shutdown take so long as to give the impression
>> it had failed entirely, then eventually work, then later work promptly?
>>
>
> 1) Gremlins. You need to exorcise your datacenter.
> or
> 2) because the first time, Tomcat had been running for a while, so it
> had a lot of things to shut down nicely and cleanup; while the second
> time, it had only be running for a much shorter time, and had less to
> clean up ?
It's not gremlins, it's magic. I see this all the time on windows: it
shuts down in the time I'm willing to wait for it ~50% of the time. The
other 50% I end up killing the task.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat shutdown.sh troubleshooting on AS/400
Posted by André Warnier <aw...@ice-sa.com>.
James Lampert wrote:
> . . . and when I looked back at the box I was testing, Tomcat *had*
> finally shut down. And when I ran both the start and stop scripts this
> time, the stop script worked perfectly (and promptly).
>
> Weird. Why would the shutdown take so long as to give the impression it
> had failed entirely, then eventually work, then later work promptly?
>
1) Gremlins. You need to exorcise your datacenter.
or
2) because the first time, Tomcat had been running for a while, so it had a lot of things
to shut down nicely and cleanup; while the second time, it had only be running for a much
shorter time, and had less to clean up ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat shutdown.sh troubleshooting on AS/400
Posted by James Lampert <ja...@touchtonecorp.com>.
. . . and when I looked back at the box I was testing, Tomcat *had*
finally shut down. And when I ran both the start and stop scripts this
time, the stop script worked perfectly (and promptly).
Weird. Why would the shutdown take so long as to give the impression it
had failed entirely, then eventually work, then later work promptly?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat shutdown.sh troubleshooting on AS/400
Posted by André Warnier <aw...@ice-sa.com>.
James Lampert wrote:
> In my experience, Tomcat's "shutdown.sh" has never worked reliably on
> AS/400, and I don't know why, or even understand enough about how it
> works (or enough about shell scripts) to troubleshoot it.
>
> Here's the script. I can tell that it eventually transfers control to
> catalina.sh (which is also what launches Tomcat), but that's about all I
> can make out without help.
>
Without looking at the Tomcat Java code itself, this is my take on it :
- shutdown.sh's main purpose is to locate and execute catalina.sh with the single argument
"stop".
- catalina.sh, when called with a "stop" argument (and without the "-force" option) :
- starts another instance of the JVM, to run another instance of Tomcat, with the
argument "stop". Let'scall this the "shutdowner" Tomcat.
- this other "shutdowner" instance of Tomcat parses the same conf/server.xml as the main
tomcat instance, and in particular the tag :
<Server port="8005" shutdown="SHUTDOWN"> (default values shown)
From there, it picks up the "shutdown port" which the main Tomcat should have opened in
LISTEN mode (iow a listening, server socket), and the string in the "shutdown" attribute.
Then this "shutdowner" Tomcat instance attempts to open a client connection to this port
on localhost, and if succesful sends the picked-up shutdown string over that connection.
Back to the running Tomcat, which is listening on that server port.
It receives the connection request from the "shutdowner" Tomcat. If the connection is made
from the same host (localhost, 127.0.0.1), it accepts it.
If so, it next receives over that connection, the string sent by the "shutdowner" Tomcat,
compares that with the string in its own <Server> tag, and if they match, it starts
shutting itself down.
Back to the "shutdowner" Tomcat : when it has been succesful opening the connection to
localhost:shutdown-port and sending the shutdown string over it, it closes the connection
and terminates. This also causes its own "catalina.sh stop" script to terminate.
And everyone is happy.
Of course, if anything in the sequence above misfires, someone will be unhappy.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org