Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?

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

Dave,
Yes that would do it.  Linux is designed for use my multiple users.
If one user renames a directory while another user is doing something
in it, then UNIX tries to avoid causing problems.  You need to cd up
to the parent directory and then back down to see the change.

Glad you figured it out.

For the TERM issue.   Did you stop the Wrapper before modifying the
script?   You need to start the Wrapper after the ignore signals flag
is set so it will be all set up to be able to stop the Wrapper
correctly.   Please let me know if you are still having problems when
you do this and I would be happy to help out further.

Cheers,
Leif

On Sun, Jun 26, 2011 at 3:11 PM, David Hoffer <dho...@gm...> wrote:
> I think I figured this out.  Because I had a putty window open to the
> original folder, when it was renamed to _folder the putty window was
> referring to the old renamed folder when running the sh script
> although other commands like ls, cd worked with the new folder.  Once
> I changed putty to the old renamed folder I could stop that service
> and then start the new one once back to the new folder.
>
> Now back to the original issue regarding how to handle rouge TERM
> commands, when I make the config change to ignore signals I now no
> longer can use the wrapper's stop command I have to use kill -9 PID.
> I really would like to use the wrapper to start/stop and not use kill.
>
> -Dave
>
> On Sat, Jun 25, 2011 at 9:47 PM, David Hoffer <dho...@gm...> wrote:
>> Lief,
>>
>> The first thing I did is cd to the directory of the prior folder and
>> stop the service (it was previously installed and started).  Then
>> after it was stopped I renamed the entire folder with the _ prefix.  I
>> then  replaced the entire folder with the same name as before.  I then
>> started the service in the new folder (same name as before).
>>
>> The log file is: wrapper.logfile=./wrapper.log
>>
>> Yes I do have two conf files one in the program folder and one in
>> _program folder but since I'm in program shouldn't it ignore the
>> _program folder?  It's acting like the program is running from
>> _program but I started it from program.
>>
>> The mysterious ways of Linux.
>>
>> -Dave
>>
>> -Dave
>>
>> On Sat, Jun 25, 2011 at 9:03 PM, Leif Mortenson
>> <lei...@ta...> wrote:
>>> Dave,
>>> On linux if you rename a file or folder which contains an open file
>>> then the existing file handle will stay attached to the file.  But if
>>> you restart the process (Wrapper) then it should load from the new
>>> location.
>>>
>>> I am not 100% clear what steps you took.   The wrapper.logfile property.
>>> http://wrapper.tanukisoftware.com/doc/english/prop-logfile.html
>>> Please check your wrapper.conf file to see where it is pointing.
>>>
>>> How are you starting the Wrapper?  Is it possible that you have two
>>> wrapper.conf files?
>>>
>>> Cheers,
>>> Leif
>>>
>>> On Sun, Jun 26, 2011 at 8:29 AM, David Hoffer <dho...@gm...> wrote:
>>>> Leif,
>>>>
>>>> Where is this symbolic link stored?  Because this was a major upgrade
>>>> I renamed the existing folder (prefixed it with _) and uploaded the
>>>> new program to the prior folder name, but now I see the log output is
>>>> going to the old renamed folder.  This would work just fine on
>>>> Windows.  Not sure what I have to do to fix any links that may point
>>>> to the renamed old folder.
>>>>
>>>> Thanks,
>>>> -Dave
>>>>
>>>> On Wed, May 18, 2011 at 5:05 PM, Leif Mortenson
>>>> <lei...@ta...> wrote:
>>>>> David,
>>>>> Just stopping should be fine.   "Installing" on a UNIX system is
>>>>> simply creating symbolic links to the script in most cases.
>>>>>
>>>>> Please let me know how it works for you.
>>>>>
>>>>> Cheers,
>>>>> Leif
>>>>>
>>>>> On Thu, May 19, 2011 at 2:10 AM, David Hoffer <dho...@gm...> wrote:
>>>>>> Leif,
>>>>>>
>>>>>> I'm about ready to deploy this change.  I understand it needs to be stopped
>>>>>> but since this is 'installed' as a daemon do I have to 'undo' that first?
>>>>>> Or just stop and restart?
>>>>>>
>>>>>> Thanks,
>>>>>> -Dave
>>>>>>
>>>>>> On Tue, May 17, 2011 at 1:09 PM, Leif Mortenson
>>>>>> <lei...@ta...> wrote:
>>>>>>>
>>>>>>> David,
>>>>>>> The controlEvent method gives you a chance to either handle or ignore
>>>>>>> the signal within the JVM process.  This is a very old API and the
>>>>>>> problem with it is that the Wrapper process may also receive a TERM
>>>>>>> signal.  If that happens, the Wrapper will proceed to initiate the
>>>>>>> shutdown process regardless of what this method does.   For this
>>>>>>> reason, this method is more useful as a reporting method.
>>>>>>>
>>>>>>> To prevent your application from responding to TERM signals, you will
>>>>>>> want to use the wrapper.ignore_signals property
>>>>>>> http://wrapper.tanukisoftware.com/doc/english/prop-ignore-signals.html
>>>>>>>
>>>>>>> On UNIX, the recommended way of doing this is to set the
>>>>>>> IGNORE_SIGNALS variable at the top of the shell script that comes with
>>>>>>> the Wrapper.  Make sure the Wrapper is stopped when this change is
>>>>>>> made as it changes the way the script controls the Wrapper.
>>>>>>> Please see the above page for more details.
>>>>>>>
>>>>>>> Let me know how this works for you.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Leif
>>>>>>>
>>>>>>> On Tue, May 17, 2011 at 5:16 PM, David Hoffer <dho...@gm...> wrote:
>>>>>>> > I have the wrapper installed on Linux as a service and need as close
>>>>>>> > to 100% up time as is possible.  The wrapper recently received a
>>>>>>> > WRAPPER_CTRL_TERM_EVENT and shut the app and wrapper down.  My
>>>>>>> > controlEvent() is like this...as copied from some JSW sample code...
>>>>>>> >
>>>>>>> > public void controlEvent(int event) {
>>>>>>> >
>>>>>>> >         try {
>>>>>>> >             if (WrapperManager.isControlledByNativeWrapper()) {
>>>>>>> >                 // The Wrapper will take care of this event
>>>>>>> >             } else {
>>>>>>> >                 // We are not being controlled by the Wrapper, so
>>>>>>> > handle the event ourselves.
>>>>>>> >                 if ((event == WrapperManager.WRAPPER_CTRL_C_EVENT) ||
>>>>>>> > (event == WrapperManager.WRAPPER_CTRL_CLOSE_EVENT) || (event ==
>>>>>>> > WrapperManager.WRAPPER_CTRL_SHUTDOWN_EVENT)) {
>>>>>>> >                     log.warn("We are handling the received event
>>>>>>> > ourselves and we are stopping the service");
>>>>>>> >                     WrapperManager.stop(0);
>>>>>>> >                 }
>>>>>>> >             }
>>>>>>> >         }
>>>>>>> >     }
>>>>>>> >
>>>>>>> > Now I see that recent javadocs say to use...(unless one knows what
>>>>>>> > they are doing)
>>>>>>> >
>>>>>>> > public void controlEvent( int event )
>>>>>>> >  {
>>>>>>> >       if ( ( event == WrapperManager.WRAPPER_CTRL_LOGOFF_EVENT )  &&
>>>>>>> > WrapperManager.isLaunchedAsService() )
>>>>>>> >        {
>>>>>>> >            // Ignore
>>>>>>> >        }  else   {
>>>>>>> >           WrapperManager.stop( 0 );
>>>>>>> >        }
>>>>>>> >  }
>>>>>>> >
>>>>>>> > It seems neither of these handle WRAPPER_CTRL_TERM_EVENT in a way that
>>>>>>> > provides 100% up time, rather it just shuts things down cleanly.
>>>>>>> >
>>>>>>> > What is the right way to handle this?  I.e. should I ignore the
>>>>>>> > signal?  should I restart after shutdown?  How?
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > -Dave