when omfwd is used with the $streamdriverpermittedpeers legacy
parameter, a memory corruption can occur. This depends on the
length of the provided strings and probably the malloc subsystem.
Once config parsing succeeds, no problem can happen.
Thanks to Brent Douglas for initially reporting this issue and
providing great analysis.
Thanks to github user bwdoll for analyzing this bug and providing
a suggested fix (which is almost what this commit includes).
closes https://github.com/rsyslog/rsyslog/issues/1408
closes https://github.com/rsyslog/rsyslog/issues/1474
now you can continue logging after switch to persistent
journal without need to restart rsyslog service.
Bumped correspondidng systemd version dependency.
The variable priorityString was not used when rsyslog acted as the
server and the defaults were always set. Now the priorityString
is used when specified.
fixes https://github.com/rsyslog/rsyslog/issues/1722
The testbench got some occasionally failing tests. Review of
them brought up the idea that there is a race during worker
threat termination. Further investigation showed that this
might be a long-standing issue, but so far did not really
surface as the timing was almost always correct. However,
with the new functionality to emit a message on worker
shutdown (v8.29), the timing got more complex and now this
seemed to occasionally surface.
closes https://github.com/rsyslog/rsyslog/issues/1754
Elasticsearch responses for bulk requests differ slightly between
versions <= 2.4 and more recent ones (5 and upwards).
As a matter of fact, they used to look like this for version 2.4 :
'{
"took":1205,
"errors":false,
"items":[{
"create":{
"_index":"log-2017.08.25",
"_type":"log",
"_id":"AV4JLGyt91GzIgdyx6s7",
"_version":1,
"_shards":{
"total":2,
"successful":1,
"failed":0
},
"status":201
}
}]
}'
Whereas they now look like this, starting from version 5 (there was no
version between 2.4 and 5):
'{
"took":1829,
"errors":false,
"items":[{
"index":{
"_index":"log-2017.08.25",
"_type":"log",
"_id":"AV4JPZ_fquWCvYqrs7tN",
"_version":1,
"result":"created",
"_shards":{
"total":2,
"successful":1,
"failed":0
},
"created":true,
"status":201
}
}]
}'
Note that the main difference is that the object "create" was renamed as
"index".
So far, the code was looking for the key "status" of this object
"create". This commit make it so that it now also tries to find the
object "index" if the object "create" does not exist.
Fixes#1731
my original patch attented to fix an deprecation warnings while sending
json related to content type.
I however wanted to improve my commit and support the mentioned x-ndjson
content type in case of bulk mode.
see
https://www.elastic.co/guide/en/elasticsearch/reference/master/docs-bulk.html
However, firstly my patch was wrong, since, in bulk mode, the x-ndjson was
set even for connection checks. Secondly I discovered that ES community
kind of disagree of what is the correct behavior:
in RFC 6648 the x- prefix is already decided as "deprecated"
see https://github.com/elastic/elasticsearch/issues/25718
So I decided to put only application/json as content type; it is
supported for both simple request or bulk requests containing multiple
json. We can improve it when there is a final decision about it.
Re-Fixes: #1642
Fixes: commit 462be8b2ee4 (omelasticsearch: avoid ES5 warnings while sending json)
Signed-off-by: William Dauchy <w.dauchy@criteo.com>
Remove the 'pThis->' from the second argument to STATSCOUNTER_INC macro.
This only affects architectures without atomic uint64 actions, like aarm64.
Others do not use the mut argument, and it gets compiled out.
fixed a bug causing incorrect debug output. Thanks
to etainativ for the fix-suggestion.
Also removed an incorrect comment (copy-paste error).
closes https://github.com/rsyslog/rsyslog/issues/1708
