You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ra...@itdz-berlin.de on 2006/02/01 11:04:47 UTC

How to identify version of a running Tomcat and similar trivia

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


Re: How to identify version of a running Tomcat and similar trivia

Posted by Tim Funk <fu...@joedog.org>.
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