hi David,
apart from using the Perl wrapper around sec for replacing HUP with USR2,
there is even simpler solution that is probably best workaround for the
problem. Since sec has a unique feature of allowing access to its internals
(you are probably using this feature already, in order to back up
contexts), you can easily change the HUP signal handler within the sec
process. Just have the following rule for overriding the handler when sec
starts up:
type=Single
ptype=RegExp
pattern=^SEC_STARTUP$
context=[SEC_INTERNAL_EVENT]
desc=override the HUP signal
action=lcall %o -> ( sub { $main::SIG{HUP} = sub { kill('USR2', $$) } } )
The new handler
sub { $main::SIG{HUP} = sub { kill('USR2', $$) } }
simply sends the USR2 signal to the sec process itself when HUP is captured.
If you want to make things even more efficient, you could set the
$main::openlog flag from the handler which indicates received USR2 and
triggers the output reopen procedure. Nevertheless, issuing USR2 uses
official signal interface and does not depend on the internal variable
name, and is thus guaranteed to work even after possible future variable
change in the code.
I think this is the best solution for the problem, since for saving and
restoring state at HUP you need at least two rules for matching sec
internal events, and there is still some state you inevitably lose at HUP.
In contrast, here you have only one rule which should do everything you
want.
kind regards,
risto
I agree it's not the best thing to do, for rotation, but here's another
> case.
>
> I have an instance of SEC that's keeping running totals of things in logs,
> and I have it writing the totals out every minute. I also have it write out
> the totals when it shuts down.
>
> But if it gets a HUP, it looses all it's current data and has no chance to
> write it out or do anything else with it.
>
> Since you mentioned a discussion in rsyslog mailing list about forwarding
>> HUP signal from rsyslog to its child processes, and possibly replacing HUP
>> with another signal, there was a somewhat similar discussion in the sec
>> mailing list few years ago. The main idea of the discussion was the
>> limitation of child process runtime, and a relevant recipe was posted to
>> the SEC FAQ: http://simple-evcorr.sourceforge.net/FAQ.html#20
>>
>
> I was starting from #15
>
>
> The above recipe can be easily reused for handling your problem by rolling
>> out a similar Perl wrapper:
>>
>> #!/usr/bin/perl -w
>> #
>> # wrapper.pl -- this wrapper starts sec and if HUP is sent to
>> # the wrapper, it sends USR2 signal to the sec process
>> #
>> if (scalar(@ARGV) < 1) { exit(1); }
>> $pid = fork();
>> if ($pid == -1) {
>> exit(1);
>> } elsif ($pid == 0) {
>> exec("@ARGV");
>> } else {
>> $SIG{HUP} = sub { kill USR2, $pid; };
>> $SIG{TERM} = sub { kill TERM, $pid; exit(0); };
>> waitpid($pid, 0);
>> exit($? >> 8);
>> }
>>
>>
>> If you start the following command line from rsyslog:
>> wrapper.pl /usr/bin/sec --conf=/etc/sec/sec.conf --notail --input=-
>> every HUP signal that is forwarded to wrapper.pl will be replaced with
>> USR2
>> and sent to sec. Also, since the sec process inherits its standard input
>> from the wrapper, it can receive input from the pipe that rsyslog has
>> created. While using a wrapper might initially seem a bit complex, rsyslog
>> v5 has to use wrapper script anyway for programs with command line options
>> (one example can be found at http://simple-evcorr.
>> sourceforge.net/FAQ.html#2).
>> With v5 you can easily modify the above wrapper for handling both tasks,
>> so
>> no additional complexity will be added to your setup.
>>
>
> I'm using v8.8, and 7.x is in current distros, so v5 stuff is very quickly
> becoming distant legacy.
>
> It's good to have options at both ends to deal with signals like this. But
> I'm not sure that this completely avoids the uses of being able to do
> something before data is lost when receiving something other than a full
> shutdown.
>
> Hope this helps,
>>
>
> It does, thanks.
>
> David Lang
>
>
------------------------------------------------------------------------------
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
