hi David, restarting SEC means that all event correlation operations executed by previous instance will be lost. Although it is possible to write custom rules for storing SEC contexts to disk at shutdown and load them at restart (e.g., see http://simple-evcorr.github.io/FAQ.html#15), there is no easy way for doing that with event correlation operations. For example, if the user deletes some rules before restart, SEC might load operations which no longer have a parent rule.
However, if you don't restart SEC but rather send it the ABRT signal, it will check the modification times of all rule files, and reload rules only from files which have been modified (note that all previous event correlation operations associated with modified files are terminated). This means that if you keep critical rules in separate rule files which you don't modify, ABRT signal does not destroy their event correlation state after you have modified other files in your rule base. For example, suppose you have two rule files test.sec and test2.sec with the following content, where test.sec contains a critical rule: # test.sec -- critical rules that don't change type=Pair ptype=RegExp pattern=test (\d+) desc=test no $1 started action=logonly ptype2=SubStr pattern2=end $1 desc2=test no $1 ended action2=logonly # test2.sec -- rules under development type=SingleWithThreshold ptype=regexp pattern=myevent (\d+) desc=count instances of myevent $1 action=logonly window=3600 thresh=3 Suppose SEC receives the following four input events: test 1 test 2 myevent 1 myevent 2 The first two events match the Pair rule from test.sec which creates two event correlation operations, with one of them waiting for event 'end 1' and the other one for event 'end 2'. On the other hand, the last two events match the SingleWithThreshold rule from test2.sec which creates two counting operations. If you change test2.sec now and send ABRT signal to SEC process, you should see the following debug messages from SEC which indicate that two SingleWithThreshold operations were terminated: SIGABRT received: soft restart of SEC Reading configuration from test2.sec ... Terminating all event correlation operations started from test2.sec, number of operations: 2 However, since test.sec was not modified, its content is not reloaded and Pair event correlation operations will continue to run. For example, if event 'end 1' would arrive now, one of the operations would match it and execute the 'logonly' action, producing the following message: "test no 1 ended". Hope this example was helpful, risto Kontakt David Thomas (<dtho...@kwiktrip.com>) kirjutas kuupäeval E, 9. september 2019 kell 18:13: > I'm about to implement an SEC rule that will be fairly critical to our > business. It is a 'Pair' rule and at any time I may have multiple events > that have matched pattern 1 and are waiting for pattern 2. > > But I have a number of other use cases for SEC that I'm eager to > implement. If at all possible I'd like to do this in a way that maintains > the events waiting for pattern 2. > > Currently I have SEC installed in a docker container and when I modify or > add a rule (which I keep in separate .sec files) I restart the docker. > This runs a command: > /usr/bin/perl -w /usr/local/bin/sec --log=/dev/stdout --debug=5 > --input=/var/log/logzilla/sec.log --input=/var/log/logzilla/sec/*.log > --conf=/etc/logzilla/sec/*.sec > > Will this lose the events that are waiting for pattern 2? > > If so is there an alternative way to add additional rules (or modify > existing rules) that will keep those events? > > Thanks. > > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users >
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
