Hello Mr. Eckel:
In message <5e1c2184-2b8f-4d7a-a8f2-970a0bdbe...@eckel-edv.de>,
Peter Eckel writes:
>I think I found a bug (or a mistake in the documentation) in SEC.
Possibly.
>The manpage says:
>
>> SEC_SHUTDOWN - generated when SEC receives the SIGTERM signal, or
>> when SEC reaches all EOFs of input files after being started with
>> the --notail option. With the --childterm option, SEC sleeps for 3
>> seconds after generating SEC_SHUTDOWN event, and then sends SIGTERM
>> to its child processes (if a child process was triggered by
>> SEC_SHUTDOWN, this delay leaves the process enough time for setting
>> a signal handler for SIGTERM).
>
>However, when I restart sec (i.e. stop and immediatels start the
>process), I get:
>
>> Mon Jul 17 12:36:36 2017: SIGTERM received: shutting down SEC
>> Mon Jul 17 12:36:36 2017: Creating SEC internal context
>> 'SEC_INTERNAL_EVENT'
>> Mon Jul 17 12:36:36 2017: Creating SEC internal event 'SEC_SHUTDOWN'
>> [...]
>> Mon Jul 17 12:36:36 2017: SEC (Simple Event Correlator) 2.7.11
>> Mon Jul 17 12:36:36 2017: Changing working directory to /
>
>No sign of any 3 second delay ...
Yup, I'll bet it's because you have no child (forked) processes. The
bit if code that implements this is:
if (exists($terminate{$$})) {
log_msg(LOG_NOTICE, "SIGTERM received: shutting down SEC");
# If -intevents flag was specified, generate the SEC_SHUTDOWN event.
# After generating SEC_SHUTDOWN event, SEC will sleep for TERMTIMEOUT
# seconds, so that child processes that were triggered by SEC_SHUTDOWN
# have time to create a signal handler for SIGTERM if they wish.
if ($intevents) {
internal_event("SEC_SHUTDOWN");
if ($childterm) { sleep(TERMTIMEOUT); }
}
# final shutdown procedures
if ($childterm) { child_cleanup(); }
exit(0);
It is looking for children i.e. processes forked and running in
the background. As you noted at the end of your original email:
>I must add that both are calling perl functions, no
>shellcmd whatsoever. One is called via lcall, the other via call.
Hence no child process to wait for.
Note that SEC literally sleeps the current thread, so your perl
functions won't be running during the sleep anyway.
However internal_event() calls process_rules(). As a result all your
rules should be run regardless of how long they take before SEC exits.
>I found this because I use two rules triggering on
>SEC_SHUTDOWN. Neither of them runs more than 3 seconds (far less, in
>fact), but depending on the order I have them processed, only one of
>them gets executed. The one that runs slightly longer, if run first,
>keeps the second from executing altogether. No log entry, no error,
>nothing - it isn't started at all.
>
>When I replace both actions with a logonly, both run fine
>irrespectively of the order, so it's quite clearly a matter of timing.
>However, with the 3 second delay it should work in any case, 3
>seconds should be ample of time for both to complete.
I think this part of your analysis is correct. I am just not sure how
they don't run to completion before SEC exits. Do these rules run in
threads or in any way create a parallel processing path to the main
SEC event loop? This could cause process_rules() to return before your
rules have completed.
Can you try adding an additional rule that fires on SEC_SHUTDOWN after
your two perl rules:
type = single
desc = make sec wait
pattern = SEC_SHUTDOWN
ptype = substr
action = shellcmd sleep 2
I am making the rule up from memory, so YMMV. The basic idea is to
create a child process to trigger SEC to wait.
With this the --childevents flag should be applied.
Hopefully Risto will have some other ideas.
Have a great day.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
