tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: How to identify version of a running Tomcat and similar trivia
Date Thu, 02 Feb 2006 03:26:11 GMT
The Http10Connector refers to HTTP/1.0.  It also means that you've got a TC 
3.x server running there.  If you've got a conf/modules.xml then it's 
probably TC 3.3.1a (since 3.3.2 uses the CoyoteConnector by default). 
Otherwise, it's probably TC 3.2.4.

It also explains why there is no /manager webapp, since it's called /admin 
in TC 3 (and is much less full-featured than /manager in later TC versions 
:).

<Ralph.Grothe@itdz-berlin.de> wrote in message 
news:D44BE377760A99459EE0C200622E13F608C6E9@itdzex001.ITDZ.verwalt-berlin.de...
Hi Tim,

thanks for referring me to the Tomcat FAQs.
That's for sure the first source of information one should read
before nagging the list community with redundant questions.
At least did I find therein a description how to enable CGI
support.

Yet, the trivial task of identifying a running Java thread's
Tomcat version seems rediculously convoluted.
I assume the mentioned version script isn't much more than a mere
wrapper script that puts together the a hundred chars long java
invocation of some class method call that most likely is called
version() along with the loading of a dozen jar libs etc. (only
joking ;-)
Anyway, far more than anyone can remember and type without making
typos.

Only problem is, my Tomcat depot on this box (randomly picked one
of our HP-UX boxes, but we also have Tomcats running on Linux,
AIX, Solaris (and probably Win32) doesn't seem to have bundled
such a wrapper script.

# swlist |grep -i tomcat
  hpuxwsTomcat                  A.4.1.29.04    HP-UX Tomcat-based
Servlet Engine

(ok, I concede with a properly bundled hpux depot I get a
revision string that happens to be the same as the bundled Tomcat
version, but that's not everywhere the case)

# swlist -l file hpuxwsTomcat|grep -cF version
0

So where can I get such a version script?
Hm, most likely in the official Apache Tomcat tarball
distribution.
Ok, I got that already for my Linux install problem (where I
first thought to be required to compile from sources by Ant).
Let's see if I find it there

$ gzip -dc apache-tomcat-5.5.15.tar.gz |tar tf -|grep -F version
apache-tomcat-5.5.15/bin/version.bat
apache-tomcat-5.5.15/bin/version.sh

Yup, let's see what its content is

$ gzip -dc apache-tomcat-5.5.15.tar.gz |tar xf -
apache-tomcat-5.5.15/bin/version.sh

$ grep EXE apache-tomcat-5.5.15/bin/version.sh
EXECUTABLE=catalina.sh
if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then
  echo "Cannot find $PRGDIR/$EXECUTABLE"
exec "$PRGDIR"/"$EXECUTABLE" version "$@"


What the hack is catalina?
Only know of an island off the coast of Los Angeles of that name,
and a nice WWII water plane.

But if I have the catalina.sh script anyway, and the only arg it
is fed with happens to be "version"
then I won't require the version script on my hpux boxes anyway.
What a production...

Then some of you mentioned a manager or admin webapp.
Is this provided along with the basic Tomact installation, or an
add-on.

Well, when I run a GET on this URI on the Http10Connector
according to this server's server.xml
(btw, what is a Http10Connector? does it refer to the maximum
bandwidth?)
I only get a 404 server response.
Seems there is further installation of a servlet required.

# wget -O - http://localhost:8081/manager/html
--16:52:07--  http://localhost:8081/manager/html
           => `-'
Resolving localhost... done.
Connecting to localhost[127.0.0.1]:8081... connected.
HTTP request sent, awaiting response... 404 Not Found
16:52:07 ERROR 404: Not Found.


Regards
Ralph


> -----Original Message-----
> From: Tim Funk [mailto:funkman@joedog.org]
> Sent: Wednesday, February 01, 2006 12:47 PM
> To: Tomcat Users List
> Subject: Re: How to identify version of a running Tomcat and
similar
> trivia
>
>
> See the FAQ. http://tomcat.apache.org/faq/
>
> There are a few ways to get the version
> 1) Use version.sh (or vertsion.bat)
> 2) Look at the manager webapp (in url /manager/html/)
> 3) More ways that I can't remember
>
> -Tim
>
> Ralph.Grothe@itdz-berlin.de wrote:
>
> > Hi Tomcatters,
> >
> > I beg your pardon for this affront to any self-respecting
servlet
> > coder's mind.
> > I am but merely a Unix sysadmin plagued with a varying zoo of
> > Tomcats on different Unices who is largely Java-ignorant and
only
> > has to maintain these cats (sorry, but Perl suits my mundane
> > admin tasks much better).
> > Nevertheless I hope you deign giving me an answer to my
trivial
> > questions.
> >
> > 1. How can I identify the version of a running Tomcat without
> > reaping it or wreaking similar havoc?
> >
> > Back in ole Apache days things where easy.
> > You only had to locate the residence of the httpd daemon's
binary
> > (which was just a glance at the proc table),
> > and run a httpd -v on it.
> > These times all I can see is a running Java master thread.
> > All it discloses is the version of the Java interpreter from
the
> > respective JRE.
> >
> > 2. How to quickly introspect a Tomcat's child thread,
resource
> > usage?
> >
> > I cannot see from the OS's proc table how many child threads
a
> > master has spawned and keeps maintaining,
> > nor which resources they share.
> > If something gets cranked up, what seems to be quite often
for
> > some of our Tomcat implementations
> > (almost never experienced a crashing Apache), all I can do is
> > killing the master thread
> > if it is still appearing in the proc table though.
> > (I assume the rather instability is owe to too many average
Java
> > hackers deem themselves eligable to tinker with the Tomcat's
> > memory management relying on automatic garbage collection,
only
> > comparing this with what I learned about mod_perl and proper
> > initializations and freeing of resources)
> >
> > 3. How to identify a Tomcat's config?
> >
> > Well, I could run a find for server.xml, but this would most
> > likely spit out a dozens of namesake files
> > of various "test" instalations that aren't of relevance.
> >
> > I think, there ought to be an URI one could query.
> >
> > For instance when I lookup the proc table on a hpux box at
best I
> > can only see this mess
> >
> > $ UNIX95= ps -x -C java -o args=
> > /opt/java1.5/bin/PA_RISC2.0/java -Xverbosegc:file=/tmp/gc.out
> > -server -Xms256m -Xmx256m -Xmn128m -XX:+DisableExplicitGC
> > -XdoCloseWithReadPending
> >
-Djava.security.policy==/opt/hpapache2/tomcat/bin/../conf/tomcat.
> > policy -Dtomcat.home=/opt/hpapache2/tomcat/bin/..
> > org.apache.tomcat.startup.Main start
> >
> > Ok, from this I could at least guess that there might be a
> > /opt/hpapache2/tomcat/conf/server.xml
> > lingering.
> >
> >
> > 4. Parsing the config
> >
> > Despite their ever increasing whitespread I think these XML
style
> > config files are a nuisance for a sysadmin
> > who neither is able to nor willing to use an X application
for
> > config maintenance, querying
> > (think of low bandwidth serial line connections and the
impedence
> > by ubiquitious firewalls)
> > I wouldn't quite argue that a sendmail.cf file is anything
more
> > readable to the human,
> > but I find it rather overkill to throw in an XML parser
module
> > (like CPAN's XML::Simple, XML::Parser or XML::SAX)
> > merely to find out basic configuration settings (e.g. like
> > listening ports).
> >
> > So is there a CLI tool or a special URI for quereing a
Tomcat's
> > config?
> >
> > 5. Tool for monitoring a Tomcat's state
> >
> > I know there's some Java Monitoring classes (was it JMX or
so?).
> > But as I told you I am not into Java, and most of all I lack
the
> > knowledge of the underlying class hirarchy.
> > It would be nice if I could use or come up with an own Perl
> > plug-in.
> > Is it possible to enable "legacy" CGI support with Tomcat?
> > Then I could at least provide my own monitoring scripts.
> >
> >
> > Regards
> > Ralph
> >
> >
> >
> >
>
-----------------------------------------------------------------
----
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> >
>
>
-----------------------------------------------------------------
----
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 




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


Mime
View raw message