wrapper-user

[Wrapper-user] Getting service status on Unix

[Mark L. <mid...@ve...>]

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

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
>   

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

[Mark L. <mid...@ve...>]

Leif,

Thanks for your response. I don't know much about Unix shell 
programming, so I didn't check the script. But after reading your post, 
I looked at it, and I think I know enough to say this it does indeed do 
what I was looking for. Probably I didn't explain it very well. I was 
hoping to use the return value from invoking the script with the 
argument "status" to tell whether the service was running. I observed 
that it returns 1 when the script is not running, and 0 otherwise. I 
didn't see this documented, so I wondered if it would always be the 
case. But doesn't the following code from the script mean that this is 
indeed the intended behavior, and I can therefore rely on it?

status() {
    getpid
    if [ "X$pid" = "X" ]
    then
        echo "$APP_LONG_NAME is not running."
        exit 1
    else
        echo "$APP_LONG_NAME is running ($pid)."
        exit 0
    fi
}

I prefer this approach to checking for the presence of the pid file, 
since, as you pointed out, the script ensures not only that a process is 
running with a pid equal to the pid in the pid file, but also that that 
process is the wrapper process.

-Mark

Leif Mortenson wrote:
> 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
>>   
>
>
>

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

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

Mark,
You are correct.  That should work for you.

Cheers,
Leif

Mark Leone wrote:
> Leif,
>
> Thanks for your response. I don't know much about Unix shell 
> programming, so I didn't check the script. But after reading your post, 
> I looked at it, and I think I know enough to say this it does indeed do 
> what I was looking for. Probably I didn't explain it very well. I was 
> hoping to use the return value from invoking the script with the 
> argument "status" to tell whether the service was running. I observed 
> that it returns 1 when the script is not running, and 0 otherwise. I 
> didn't see this documented, so I wondered if it would always be the 
> case. But doesn't the following code from the script mean that this is 
> indeed the intended behavior, and I can therefore rely on it?
>
> status() {
>     getpid
>     if [ "X$pid" = "X" ]
>     then
>         echo "$APP_LONG_NAME is not running."
>         exit 1
>     else
>         echo "$APP_LONG_NAME is running ($pid)."
>         exit 0
>     fi
> }
>
> I prefer this approach to checking for the presence of the pid file, 
> since, as you pointed out, the script ensures not only that a process is 
> running with a pid equal to the pid in the pid file, but also that that 
> process is the wrapper process.
>
> -Mark
>
> Leif Mortenson wrote:
>   
>> 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
>>>   
>>>       
>>
>>