In message <4978112e.1050...@willingminds.com>,
"Mark D. Nagel" writes:
>John P. Rouillard wrote:
>> This is really useful when adding new rules as it stops me from having
>> to stop and restart SEC (so I don't loose state) when I am debugging a
>> new ruleset.
>
>Not to be ungracious in the least, but why not just change the debug
>flag in the SECRC file and reload?
a) because I forgot that SECRC exists
b) even using SIGABRT changes the state of the current SEC engine
by potentially reloading rules files and sending a SEC_SOFTRESTART
event.
c) it's more difficult to do automatically (see below).
>I still like this change because it
>saves an edit cycle, but if you make use of SECRC, you can still make
>that change without a full restart.
That's true but with the risk of changing internal state, that I grant
isn't a huge risk.
I have a couple of external monitors that detect when things aren't
correlating right. If one of them detects a problem it keeps sending
signals till the debug level is at 6.
Also the way I set up my config files for SEC, none of them are
writable to the user SEC is running under (which is also the user the
monitoring programs run under). So the monitoring/response progs would
not be able to use the SECRC method. But the nice part of the SECRC
method is you can set the debug level directly and don't need to get
feedback from SEC on its debug level.
Thanks for pointing that out.
As soon as Risto releases 2.5, I get to shut down a SEC process that
has been running since 2007.
nagios 30852 1 2 2007 ? 9-17:38:44 /usr/bin/perl
-w /tools/sec/bin/sec --input /var/spool/nagios/event_stream
--input /var/log/nagios/nagios.log=NAG_LOG
--input /var/spool/nagios/sec.cmd=CONTROL
--conf /etc/nagios/sec/*.sr --dump sec_dump.txt
--log sec_log.txt --pid sec_pid.txt --intevents --intcontexts
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
