|
From: David H. <dho...@gm...> - 2011-06-26 12:49:30
|
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 > |