Re: [Wrapper-user] Getting service status on Unix

[Leif M. <le...@ta...>]

Mark,
The shell script on UNIX does not currently work that way.  It would
be easy to modify the shell script to do so however when it is called
with the "status" command.

As an alternative, would checking for the pid file work for you?  The
Wrapper can be configured to output a pid file on startup.  This is
the norm when using the provided shell script on UNIX but needs
to be set on Windows: wrapper.pidfile

You can also check for a running JVM with the wrapper.java.pidfile
property.

If you want more detail on the exact status of the Wrapper or JVM
processes, you could also use the wrapper.statusfile and
wrapper.java.statusfile properties.

See the documentation for all of the above.
http://wrapper.tanukisoftware.org/doc/english/properties.html

Just so you are aware, the pid file will always be deleted if the
Wrapper shuts down normally, but it could be left around if the
Wrapper were to crash or be killed with kill -9.  Same if the OS
itself were to crash.  The shell script works around these cases
by actually looking for the process located within the pid file.

Cheers,
Leif

Mark Leone wrote:
> I'm using Runtime.exec() Java method to execute the Unix script that was 
> re-named to the name of my app. Thus I use
>
> String[] cmd = new String[]{myPath + "/myAppName" ,"status"};
> Process process = Runtime.getRuntime().exec(cmd);
>
> I can capture the standard output from process, and get a verbal 
> description of the status of the service. However I'd prefer to get an 
> integer or byte status, the way it works with Windows (executing 
> wrapper.exe, not the script). So instead of capturing standard out from 
> the Process created by exec(), I use
>
> int result = process.waitFor();
>
> When I do this, result = 1 if the service is not running, 0 if the 
> service is running. (If I get the status of executing "wrapper -qs 
> ../conf/wrapper.conf" as with Windows, I get result = 1 no matter if the 
> service is up or down.) I don't see this status result documented 
> anywhere for the Unix script. Is this behavior I can rely on, or should 
> I parse the standard output from process to determine the status of the 
> service? I'm trying to avoid the latter, because I'm having trouble 
> processing the standard output from process when I invoke exec() from 
> the Event Dispatch Thread, which I need to do.
>
> -Mark
>