In message <CAFz9LftBUMJF9o2kTN-EvHbCAA6BZd19=s8rew0g3bojydu...@mail.gmail.com> , Andy Smith writes:
>I havent used SEC before and my normal role as a Xymon admin would see me >working on various *NIX platforms, but I have been set a challenge on >Windows and I think SEC is an appropriate solution. > >So far I have installed Active State Perl and configured it to run >sec.plas a WIndows service using ABC_SrvAny and successfully got >exceptions from the target application delivered to my Xymon server >for dispatch. > >Right now is an intensive period of tuning the rules as the testers keep >finding new ways to break the app and the developers want more intelligence >in the monitoring. I couldnt find any way to send a HUP to a windows >process so every rule change at the moment requires me to restart the >service. Does the running sec report a pid in the pid file? If so http://docs.activestate.com/activeperl/5.8/lib/pods/perlipc.html demonstrates the use of kill("TERM", $kidpid), so maybe you could write your own kill perl program? Hopefully the pid generated by SEC running under activestate perl is useful to other invocation of activestate perl to id the proper process. I always run my SEC under cygwin which provides a real kill(1) process, ps etc so I don't have a solution for a pure windows environment. >Moreover, any command line changes are buried in the Registry >under the service key and are not straight forward to modify. I know I >could wrap perl in a .bat and export a SECRC variable but I liked the >elegance of running perl directly. Yeah the SECRC env variable is probably the way to go. But note that some changes to SECRC don't actually work right on restart. >So, a couple of things would help me at the moment and I seek the wisdom on >this list to see if they are possible. > >1) could I have a calendar rule that would look at the timestamp of the >config file cause sec to reload if it were modified. Rather than a calender rule, you may want to implement a control channel/input. See: http://www.cs.umb.edu/~rouilj/sec/rulesets/Readme.txt http://www.cs.umb.edu/~rouilj/sec/rulesets/01control.sr which starts SEC with an input control file to which you can write commands that perform explicit actions to the running SEC process. Appending "kill HUP" to the control file will trigger the following single rule something like: desc = implement signal handling type = single ptype = regexp pattern = ^kill (TERM|HUP|ABRT|...)$ action = eval %r ( kill("$1", $$); ) where $$ is the pid of the SEC process. I think the eval syntax is right but you may have to change it a bit s I am working from memory. I assume this work since the active state code above using kill implies that a perl process can signal another activestate process (or I hope signal itself). This is better than a calendar rule as it takes effect much quicker. You could probably come up with a perl function triggered from a calendar rule that reads a file. Then depending on the data read sends a kill to the current process, but I think the control channel is more general and more useful. > Actually, could that functionality be built into SEC natively? It needs to be an option, and is probably not that likely to to be used often. If you edit a file in place and accidentally save it with a syntax error, you don't want your running SEC to load it before you have a chance to run sec -testonly against it. Also in complex rulesets you may change many config files and not want to send a signal until all changes are in place. Also you may want to send signal say at midnight to synchronize the change with certain rules/contexts timing out etc. I think a control file mechanism is probably a better choice if you can perform the proper access restrictions on the file under windows. >2) could a command line option be added to read a given resource file? I thought this had been brought up and was impractical for some reason, but I can't find a discussion about it. >This wouldn't save me having to restart the service, but at least I >wouldn't need to go into the registry as well. Even nicer would be if the >timestamp of the resource file could be tracked in the same way as 1). I would also like a secrc command line variable, but again auto-restart should be an option. -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
