The current value (5 minutes) seemed excessevily wrong and should
probably indicate an error in any case. The new value of 2 minutes
should be fairly safe as well.
with the recent change that permits us to emit error messages at
(alomost) any time, we can now provide better end-user diagnostics.
This patch generates error message which could previously only be
logged to the debug log.
Package libqpid-proton3-dev is no longer available for precise.
As such, we cannot install it and so we disable both the installation
and related tests when running on precise.
Those messages previously went only to the debug log, as due to
design limitations inside the error message subsystem they could
not be emitted at the related code locations. This has changed now,
and so we can improve error reporting.
on error path, if iRet != RS_RET_OK, and ->pDrvrName is non-null,
->pDrvrName is freed and should be set to NULL. However, that was not
true, because what code does now, is, on every iRet != RS_RET_OK sets
pDrvrName to NULL.
Signed-off-by: Nikola Pajkovsky <npajkovsky@suse.cz>
ZMQ_SUB supports subscribing to every topic, and it's indicated by an
empty string being passed as a topic.
Fix the config parsing to correctly interpret an empty string passed as
a parameter.
This fixes a regression introduced in 8.19 by commit:
299f5a637f97d2ec064ad3df20fa845ef4b7c7e5
By default it makes sense for ZMQ_SUB and ZMQ_DISH sockets to
connect, as that's the most common use case, unless specified by the
endpoint syntax.
Regression introduced in 8.19 by commit 299f5a637f97d2ec064ad3df20fa8
The bug was introduced by the changes for the multilevel wildcard feature
which has been added recently. We have to handle FileCreate events different
if the directory watch is configured or added dynamically.
closes https://github.com/rsyslog/rsyslog/issues/1452
previous code could deadlock if internal messages were issued
inside queue processing code, which effectively limited
error-reporting capabilities. This change makes it possible
to call error messages from any part of the code at any time.
This comes at the price of slightly delayed message output.
This occured when liblogging-stdlog was used, and was used by default (without
explicit configuration). This is a regression of the new default, which does
not correctly call stdlog_open() in the default case.
closes https://github.com/rsyslog/rsyslog/issues/1442
