|
From: Leif M. <lei...@ta...> - 2011-06-26 13:49:14
|
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 |