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
>>>   
>>>       
>>
>>