tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: Any tools to detect tomcat services failure, and start it again automatically?
Date Thu, 11 Nov 2010 08:40:49 GMT
On 10/11/2010 21:50, Christopher Schultz wrote:
> Bill,
> On 11/7/2010 2:35 AM, Bill Wang wrote:
>> Thanks to Christopher , Rainer, and Rainer again. I will try to understand
>> the jsvc.
>> But for SMF, because we don't run tomcat as root, I am not sure if SMF can
>> be set and run by normal user. I need check that first.
>> My idea is, for most applications, normally I get three options: start, stop
>> and status. But tomcat's has only two choices, startup and
>> shutdown.  I can't find exist command/script to show the tomcat status. If I
>> can show the status, I can write the script to start the tomcat, when its
>> status show tomcat service is down.
>> So is it possible to ask tomcat develop team to write a general script or
>> tool to detect tomcat status directly?
> You could log an enhancement in bugzilla. As always, patches are
> welcome. Just understand that almost all code needs to be deployed into
> a web application, and you might not be able to convince most Tomcat
> users to deploy a special web application merely to provide status
> information.
> It might be better to define protocol for determining status (such as a
> simple HEAD request to a configurable URL that returns a specific string
> in the response, or a specific HTTP response code if everything is okay)
> and then write a small piece of code to check it from the command line
> and integrate that into Provide a sample implementation
> (.jsp?) and let users choose how they want to do reporting.
> The reason something like this doesn't really exist is that it's so
> poorly defined. What is "healthy" for one webapp/server might not be
> sufficient for another one.
> -chris

You could set CATALINA_PID and check that the process ID* contained in
the file is active.


* Assuming that the process id is the right one, as I have a vague
memory about it being the wrong one.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message