This is a regression from an old change (didn't track it down precisely,
but over a year ago). It used the Forwarding template instead of
the file template (so we have a full syslog header). This fix corrects
it back to previous behaviour, but new scripts that used the wrong
format may now need to have the RSYSLOG_ForwardingFormat template
explicitely be applied.
closes: https://github.com/rsyslog/rsyslog/issues/50
(hopefully now) closes: https://github.com/rsyslog/rsyslog/issues/35
When it was present, but nobody reading from it. The problem
is the way the rsyslog v7 engine tries to resolve failures in outputs.
It does some retries, and along those lines some state information gets
lost and it is close to impossible to retain it. However, the actual
root problem is that ompipe does not reliably detect if it is able to
recover. The problem here is that it actually does not know this
before it does an actual write. These two things together mess up the
logic that suppresses invalid resumption/suspension messages
(actually, the plugin switches state really that often).
Nevertheless, the prime problem with /dev/xconsole (and probably
most other pipes as well) is that it gets full. So I have now added
code that checks, during resume processing, if the pipe is writable.
If it is not, resume is deferred. That should address the case.
NOTE: this merge has problems, to be fixed with follow-up commits
If file creation fails due to out of memory, we can enter a tight loop.
Conflicts:
ChangeLog
configure.ac
doc/manual.html
runtime/parser.c
runtime/rsyslog.h
tests/Makefile.am
tests/tcpflood.c
The capability has been added for module to specify that they do not
like being unloaded.
related bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=222
Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
The output interface has been changed, but we do not yet utilize the
new interface. Also, it looks like a regression was introduced. But before
hunting it down, I'd like to make a commit (what also easys the regresion
hunt).
This was not honored by the new ompipe module, because it is a local
file directive (it was applied to pipes as a side-effect of using the
same module for pipes and files...). I now made this a global, so that
semantics are the same as previously. Not really nice, but probably
the best thing to do in the current situation (everything else would
involve much more overhead --- leave that for the new config system).
... based on old omfile. Michael Biebl reported that xconsole seems
to have some issues with the new pipe code, so it was best to use
the old code for pipes. The optimizations were done to speed up file
access, so it doesn't really matter pipes do not receive them.
