There was a race in iminternalAddMsg(), where the mutex is
released and after that the passed message object is accessed.
If the mainloop iterates in between, the msg may have already
been deleted by this time, resulting in a segfault.
Most importantly, there is no need to release the mutex lock
early, as suggested by current code. Inside mainloop the mutex
is acquired when it is time to do so, so at worst we'll have a
very slight wait there (which really does not matter at all).
This only happens if a large number of internal messages are emitted.
closes https://github.com/rsyslog/rsyslog/issues/1828
We have seen cases where the kill() used to signal new messages
actually cases problems and the new debug message is intended to
provide a better clue to what is happening. In any case, this
is generally useful, and so should remain even after the debugging
of that special case.
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.
now cleaner and hopefully usuable as a basis for loadable parser
modules. I also cleaned up/consolidated some of the internal
message generation functionality in rsyslogd.
- enhanced config file checking - no active actions are detected
- added -N rsyslogd command line option for a config validation run
(which does not execute actual syslogd code and does not interfere
with a running instance)
- somewhat improved emergency configuration. It is now also selected
if the config contains no active actions
- rsyslogd error messages are now reported to stderr by default. can be
turned off by the new "$ErrorMessagesToStderr off" directive
Thanks to HKS for suggesting these new features.
