Hi, thanks both for the replies, I fully understand the caution around
autorestart, but I am considering a situation where the rules get proved in
non-prod and then pushed to the prod servers, Xymon has a mechanism to
achieve this and I wanted to avoid having to follow the rules out to each
windows box (there are many, well enough for this to be a PITA).
I now have a service wrapper to export the SECRC, but next I am going to
abandon ABC_SrvAny because it has removed any ability to do any signal
handling in the wrapper. In the meantime, I can confirm that the pid file
contains a valid pid under ActiveState, but my kill program is not able to
signal this pid, so I have implemented the control channel as suggested.
Here my (slightly modified) rule :-
type = single
continue=dontcont
desc = implement signal handling
ptype = regexp
pattern = ^kill (TERM|HUP|ABRT)
action = eval %r ( kill("$1", $$$$); )
and here the output which SEC emits but instead of HUP, it seems to be
interpreted as a TERM because at this point, perl has gone away.
Mon Feb 17 13:52:24 2014: Evaluating code 'kill("HUP", $$);' and setting
variable '%r'
Have I got the eval incorrect, or is this ActiveState perl just not
honoring signals as I expect?
Thanks
--
Andy
On 15 February 2014 10:12, Risto Vaarandi <risto.vaara...@gmail.com> wrote:
> 2014-02-15 1:13 GMT+02:00 John P. Rouillard <rou...@cs.umb.edu>:
>
>>
>> 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.
>>
>
> I would second to John's opinion. Having an autorestart when the rule file
> modification time changes can be quite dangerous. As John pointed out, you
> might be editing a complex rule file, and any saving of intermediate file
> content would then trigger a restart. More importantly, SEC can be
> restarted in two different ways -- you could have a full restart or soft
> restart. Using a signal or a special input channel allows for controlling
> both the time and the type of restart which is not possible with the
> autorestart mechanism.
> kind regards,
> risto
>
------------------------------------------------------------------------------
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
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
