Menu
▾
▴
Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?
|
From: David H. <dho...@gm...> - 2011-06-26 19:12:27
|
I'm using version 3.5.6, perhaps that's the problem I need to upgrade? -Dave On Sun, Jun 26, 2011 at 7:49 AM, Leif Mortenson <lei...@ta...> wrote: > Dave, > I just went back and retested this with 3.5.9 and it appears to be > working correctly. > > What version of the Wrapper are you using? Please open the shell > script in an editor and make sure that the version of the script is > the same as that of the Wrapper. > > The ignore_signals mode of the script works by using an anchor file > created in the same directory as the wrapper binary. It will be named > wrapper.anchor by default. The Wrapper will shut itself down when > this file is deleted. Please confirm that this file exists while the > Wrapper is running then try to delete it manually. > http://wrapper.tanukisoftware.com/doc/english/prop-anchorfile.html > > Cheers, > Leif > > On Sun, Jun 26, 2011 at 9:49 PM, David Hoffer <dho...@gm...> wrote: >> Lief, >> >> Yes, the first thing I did is stop the service, then I modified the >> config to ignore signals then I started the service, when I tried to >> stop it...the script tried over and over to stop it but could not >> not...so I Ctlr-C to stop the script and I killed the service with >> kill -9 PID (because without the -9 kill didn't stop it either). >> >> Once I put the script back the way it was I can start/stop using the script. >> >> Thanks, >> -Dave >> >> On Sun, Jun 26, 2011 at 6:43 AM, Leif Mortenson >> <lei...@ta...> wrote: >>> 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 > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > _______________________________________________ > Wrapper-user mailing list > Wra...@li... > https://lists.sourceforge.net/lists/listinfo/wrapper-user > |
