- added fallback for _PID proprety when SYSLOG_PID is not available
- introduced new option "usepid" which sets which property should
rsyslog use, it has 3 states system|syslog|both, default is both
- deprecated "usepidfromsystem" option, still can be used
and override the "usepid"
- it is possible to revert previous default with usepid="syslog"
This is resolving the situation when system is after reboot and boot_id doesn't match
so cursor pointing into "future".
Usually sd_journal_next jump to head of journal due to journal aproximation,
but when system time goes backwards and cursor is still invalid, rsyslog stops logging.
We use sd_journal_get_cursor to validate our cursor.
When cursor is invalid we are trying to jump to the head of journal
This problem with time should not affect persistent journal,
but if cursor has been intentionally compromised it could stop logging even
with persistent journal.
Looks like a long standing off-by-one comparison issue with the
invocation of strncmp. The constant string was only 3 or 6 characters
long, but the comparison length was 4 or 7.
We have dropped this code entirely since it was not working at all.
It is an error to pass an empty message to
parser.SanitizeMsg() and doing so could crash the daemon. Besides,
there's no point in doing so in the first place.
This option is analogous to the option of the same name from imuxsock.
When set, the PID is taken from the journal rather than the message.
Conflicts:
plugins/imjournal/imjournal.c
This change makes these directives available for imjournal:
$ControlCharacterEscapePrefix
$DropTrailingLFOnReception
$Escape8bitCharactersOnReceive
$EscapeControlCharacterTab
$EscapeControlCharactersOnReceive
$SpaceNLOnReceive
Some messages comming from journald don't have the SYSLOG_FACILITY
field. These are typically the messages logged through journald's
native API. Set the default facility for these messages to 'user'.
Some messages comming from journald don't have the SYSLOG_PRIORITY
field. These are typically the messages logged through journald's
native API. Set the default severity for these messages to 'notice'.
and make imjournal use it.
The new mode is needed, as imjournal uses journal's timestamp
as message generation time (which otherwise is when the message
entered the system, and the ratelimiter uses this as current
timestamp in order to save performance).
It is debatable if imjournal is doing the right thing here. But
it doesn't feel totally wrong. So let's safe that debate for
later ;)
This option specifies whether imjournal should ignore messages
that are currently in journal. This option is only used when there
is no StateFile to avoid message loss.
modified: doc/imjournal.html
modified: plugins/imjournal/imjournal.c
Conflicts:
doc/imjournal.html
plugins/imjournal/imjournal.c
The original imjournal code did not support ratelimiting at all. We
now have our own ratelimiter. This can mitigate against journal
database corruption, when the journal re-sends old data. This is a
current bug in systemd journal, but we won't outrule this to happen
in the future again. So it is better to have a safeguard in place.
By default, we permit 20,000 messages witin 10 minutes. This may
be a bit restrictive, but given the risk potential it seems reasonable.
Users requiring larger traffic flows can always adjust the value.
This prevents a segfault when a malformed journal entry field doesn't
contain an equal sign. Should not ever happen but was actually
triggered by a real bug in systemd journal.
