On Tue, 31 Mar 2015, Rainer Gerhards wrote:
2015-03-31 12:27 GMT+02:00 Rainer Gerhards <rgerha...@hq.adiscon.com>:
2015-03-31 1:25 GMT+02:00 David Lang <da...@lang.hm>:
On Wed, 25 Mar 2015, Rainer Gerhards wrote:
2015-03-25 12:06 GMT+01:00 Rainer Gerhards <rgerha...@hq.adiscon.com>:
2015-03-25 11:49 GMT+01:00 Rainer Gerhards <rgerha...@hq.adiscon.com>:
2015-03-24 23:22 GMT+01:00 David Lang <da...@lang.hm>:
when rsyslog gets hupped (closing it's outputs), omprog currently does
nothing, so programs that it's running keep writing to anything they
have
open.
there should be an option so that when rsyslog is sent a hup, it sends
a hup
to the binaries it's managing via omprog.
sounds like a great idea. I begun to implement it, but notice that the
module interface is missing some capabilities. Right now, I don't can
enumerate the worker instance data pointers. So it's a larger change.
Not sure if I get it done today. If you don't hear back, please ping
me mid next week.
I added a tracker just in case. It also has some more info:
https://github.com/rsyslog/rsyslog/issues/281
David,
things progressed better than I thought. Could you please try this branch:
https://github.com/rgerhards/rsyslog/tree/rger-omprog-hup
This should activate HUP forwarding (default is off):
action(type="omprog" binary="..." hup.forward="on")
I've only given it very brief testing. The patch set also needs some
cleanup and doc. I'll do that as soon as time is left. In the
meantime, some feedback would be great.
I haven't had a chance to test this, but I discovered that the signal to be
passed along is not always HUP.
In the case of sec, HUP is a full restart that breaks correlations, USR2 is
log rotation (closing all outputs)
so instead of hup.forward="on" it will need to be something like
signal.rotate="USR2"
OK, I'll see I change it that way. Makes sense.
David, I think it makes sense to limit the signals that can be sent.
I'd say to the set HUP, INT, USR1, USR2, TERM (maybe). Are others
required? If so, why? Or do we need the full set?
I don't know, it's all going to depend on the software in use. While I
understand the desire to limit the list for safety, I think there is always
going to be some special case that wants something we didn't think of. since
this is an explicit config, only going to a child process that rsyslog starts, I
don't see a big risk of allowing everything (but there's always the potential
for something I don't think of)
from the SEC manual
SIGNALS
SIGHUP
full restart -- SEC will reinterpret its command line and resource file
options, reopen its log and input files, close its output files and sockets
(these will be reopened on demand), reload its configuration, and drop *all*
event correlation state (all event correlation operations will be terminated,
all contexts will be deleted, all action list variables will be erased, etc.).
With the --childterm option, SEC will also send the SIGTERM signal to its child
processes.
SIGABRT
soft restart -- SEC will reinterpret its command line and resource file
options, reopen its log file, and close its output files and sockets (these will
be reopened on demand). If the --keepopen option is specified, previously opened
input files will remain open across soft restart, otherwise all input files will
be reopened. SEC will (re)load configuration from rule files which have been
modified (file modification time returned by stat(2) has changed) or created
after the previous configuration load. SEC will also terminate event correlation
operations started from rule files that have been modified or removed after the
previous configuration load. Other operations and previously loaded
configuration from unmodified rule files will remain intact. Note that on some
systems SIGIOT is used in place of SIGABRT.
SIGUSR1
detailed information about the current state of SEC (performance and rule
matching statistics, running event correlation operations, created contexts,
etc.) will be written to the SEC dumpfile.
SIGUSR2
SEC will reopen its logfile (useful for logfile rotation), and also close
its output files and sockets which will be reopened on demand.
SIGINT
SEC will increase its logging level by one; if the current level is 6, the
level will be set back to 1. Please note this feature is available only if SEC
is running non-interactively (e.g., in daemon mode).
SIGTERM
SEC will terminate gracefully. With the --childterm option, all SEC child
processes will receive SIGTERM.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
