hi Bond,
there is no time limit for the shutdown procedure. In fact, since sec is a
single-threaded tool, it would be impossible to impose such a timeout. In
your rule example, the execution of the 'action' field prevents sec from
doing anything else, and since your 'action' field does not seem to contain
any actions that would fork background processes, the entire action list is
executed before sec can continue with other activities.
The only timeout that sec applies is for child processes which are running
at the moment of termination. The logic works as follows -- firstly, sec
processes the SEC_SHUTDOWN event (that would also include your rule), then
the sec process will sleep for 3 seconds, and finally the TERM signal will
be sent to all child processes and sec will call exit(0). However, since
the database disconnect is not done in a child process, the 3 second
timeout has no effect to your rule.
What I am suspecting is one of the following:
1) the SEC_SHUTDOWN event does not reach your rule under some circumstances
(there might be a preceding rule in your rule sequence which produces
occasional matches),
2) the TERM signal is sent by a script or application which delivers the
KILL signal to the sec process, once it has discovered after couple of
seconds that the sec process is still running.
If you want to check scenario 1, you start the action list with 'logonly'
statement and see if this produces a message about the start of execution.
Just out of curiosity -- how exactly is the TERM signal delivered to the
sec process?
kind regards,
risto
2015-10-21 22:23 GMT+03:00 Bond Masuda <bond.mas...@jlbond.com>:
> In my SEC rule set, I am using an SQLite in-memory database to cache
> data. When I shutdown SEC, I save this sqlite database to disk and
> reload it into memory when SEC starts.
>
> I've now observed several times, and it seems to be when the database is
> large, that the save to disk procedure during SEC_SHUTDOWN doesn't
> complete. In fact, I try to log messages so I have an idea of success or
> failure of the $dbh->sqlite_backup_to_file() call; and I sometimes get
> neither success nor failure log messages; SEC just shuts down. Here is
> the log when this happens:
>
> Wed Oct 21 15:00:50 2015: SIGTERM received: shutting down SEC
>
> This is what I expect, and when it works normally:
>
> Tue Oct 20 22:28:24 2015: SIGTERM received: shutting down SEC
> Tue Oct 20 22:28:26 2015: INFO: database saved to disk on attempt 1.
> Tue Oct 20 22:28:26 2015: INFO: database disconnect successful.
>
> This is my rule during SEC_SHUTDOWN:
>
> # save database to disk
> type=Single
> ptype=SubStr
> pattern=SEC_SHUTDOWN
> context=[SEC_INTERNAL_EVENT]
> continue=TakeNext
> desc=Save database to disk
> action= lcall %ret -> ( sub{ \
> my $db_backup = '/var/lib/sec/cache.sqlite3'; \
> my $tries = 0; \
> my $ret; \
> my $msg; \
> my @return; \
> do{ \
> $ret = $dbh->sqlite_backup_to_file($db_backup); \
> $tries++; \
> } until ( $ret && ($tries <= 5) ); \
> push(@return,$ret); \
> if( $ret == 1 ){ \
> $msg = "database saved to disk on attempt $tries."; \
> } else { \
> $msg = $DBI::errstr; \
> } \
> push(@return,$msg); \
> return @return; \
> } ); \
> lcall %is_success %ret -> ( sub{ \
> my ($rc, $msg) = split(/\n/,$_[0]); \
> return $rc; \
> } ); \
> lcall %msg %ret -> ( sub{ \
> my ($rc, $msg) = split(/\n/,$_[0]); \
> return $msg; \
> } ); \
> if %is_success ( logonly INFO: %msg ) \
> else ( logonly CRIT: database failed to save to disk ); \
> lcall %ret -> ( sub{ \
> my $ret = $dbh->disconnect(); \
> return $ret; \
> } ); \
> if %ret ( logonly INFO: database disconnect successful. ) \
> else ( logonly CRIT: database disconnect failed. )
>
> As you can see above, either success or failure should log a message,
> but when this problem occurs, I get nothing. So, I'm wondering if during
> SEC shutdown, is there a time limit on how long the shutdown procedure
> has before it just exits completely? I wonder if when the database is
> large, that the save to disk procedure takes too long and SEC just
> exists without allowing it to complete? Is this possible?
>
> Thanks
> Bond
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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
