Menu
▾
▴
Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?
|
From: David H. <dho...@gm...> - 2011-06-26 03:47:46
|
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 > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
