|
From: Leif M. <le...@ta...> - 2004-12-06 09:54:12
|
Stephane,
Ok, this was a bug in the shell script. The pid file is created
after the working dir is
changed but that is not taken into account by the shell script.
I have fixed this for the next release. The shell script will now
always use fully qualified
paths to avoid this issue. I have attached the new shell script. It
should work for old
versions of the Wrapper.
Let me know how it works for you.
Cheers,
Leif
Stéphane RIFF wrote:
> The user is the same (sure).
>
> The directory tree is :
> serviceroot
> |
> ---bin
> | |
> | ---wrapper
> | |
> | ---sh.script
> |
> ---conf
> | |
> | ---wrapper.conf
> |
> ---lib
> |
> ---logs
>
> In the wrapper.conf : wrapper.working.dir="../"
> In sh.script : PIDDIR="."
>
> When i start the service (with user "steff"), the MYAPP.pid file is in
> the "serviceroot" directory.
> When i want to stop (with user "steff"), the sh.script complains that
> "service not running". but
> if i print $PIDFILE in the sh.script, it display : "./MYAPP.pid" :
> seems good if the working directory
> is really set to "serviceroot"
>
> Maybe i missunderstood about working dir but if someone can points me
> to the right solution.....
> Thanks to answerers
>
> Leif Mortenson wrote:
>
>> Stephane,
>> My first guess here is a permission problem. Are you starting
>> the wrapper as the same
>> user that you are later attempting stop it with? I may have some
>> problems there but I have
>> not heard of any to date. Give me a little more info and I'll go
>> back and look over the
>> script some more.
>>
>> Cheers,
>> Leif
>>
>> Stéphane RIFF wrote:
>>
>>> I have problem with the pid file :
>>> in sh.script.in i have PIDDIR=".", the 'start ' command seems to
>>> place pidfile in the right location.
>>> but when i try to launch a 'stop' command the script tell me that
>>> the daemon isn't running .
>>>
>>> I also echo some variable and the $PIDFILE is : "./MYAPPNAME.pid" so
>>> i don't understand why the line : "if [ -f $PIDFILE ]" is not true
>>>
>>> I don't know if i'm understandable but i suspect there a problem
>>> with the sh.script.in and the wrapper.working.dir.
>>>
>>> any hints are welcome
>>> Thanks
>>
|