Menu
▾
▴
Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?
|
From: David H. <dho...@gm...> - 2011-06-27 00:24:29
|
I don't think that's it as I always started/installed/stopped from the bin folder...but I did rename that folder using a remote FTP tool and then recreated the old folder using the same FTP tool...apparently Linux doesn't like that... I'm good with upgrading to 3.5.9...no point in not doing so. -Dave On Sun, Jun 26, 2011 at 5:01 PM, Leif Mortenson <lei...@ta...> wrote: > Dave, > The following is from the 3.5.7 release notes. Is this maybe what > you are seeing? > --- > Fix a problem in the shell script that was preventing the script from > finding the running Wrapper process when it was started when the > working directory was in the same directory as the Wrapper binary, but > queried later from another location. It would also fail if it was > started from another location, but then queried from the location of > the Wrapper. This was introduced in 3.5.6 when the script stopped > changing the working directory in the script. > --- > > It would happen if you started the Wrapper from within the > $APP_HOME/bin directory as "./myapp start", but then stopped it from > the $APP_HOME directory as "bin/myapp stop". > > The following was also fixed in 3.5.7: > --- > Fix a problem in the shell script where it would fail to recognize a > running Wrapper if the Wrapper command line or path contained a square > bracket. > --- > > The full list of changes can always be found here: > http://wrapper.tanukisoftware.com/doc/english/release-notes.html > > There have been other issues fixed and improvements made as well, if > you upgrade then I recommend upgrading to 3.5.9. > > Cheers, > Leif > > On Mon, Jun 27, 2011 at 4:12 AM, David Hoffer <dho...@gm...> wrote: >> 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 > |
