Menu
▾
▴
Re: [Wrapper-user] How to properly handle WRAPPER_CTRL_TERM_EVENT?
|
From: Leif M. <lei...@ta...> - 2011-06-27 00:55:05
|
Dave, Great. Please let me know how 3.5.9 works for you. Cheers, Leif On Mon, Jun 27, 2011 at 9:24 AM, David Hoffer <dho...@gm...> wrote: > 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 |
