Changelog for 7.3.7 (v7-devel)
Version 7.3.7 [devel] 2013-03-12
- add support for anonymizing IPv4 addresses
- add support for writing to the Linux Journal (omjournal)
- imuxsock: add capability to ignore messages from ourselves
This helps prevent message routing loops, and is vital to have if omjournal is used together with traditional syslog. - field() function now supports a string as field delimiter
- added ability to configure debug system via rsyslog.conf
- bugfix: imuxsock segfault when system log socket was used
- bugfix: mmjsonparse segfault if new-style config was used
- bugfix: script == comparison did not work properly on JSON objects
- bugfix: field() function did never return “***FIELD NOT FOUND***”
instead it returned “***ERROR in field() FUNCTION***” in that case
Changelog for 7.2.6 (v7-stable)
Version 7.2.6 [v7-stable] 2013-03-05
- slightly improved config parser error messages when invalid escapes happen
- bugfix: include files got included in the wrong order
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=411
This happens if an $IncludeConfig directive was done on multiple files (e.g. the distro default of $IncludeConfig /etc/rsyslog.d/*.conf). In that case, the order of include file processing is reversed, which could lead to all sorts of problems.
Thanks to Nathan Stratton Treadway for his great analysis of the problem, which made bug fixing really easy. - bugfix: omelasticsearch failed when authentication data was provided … at least in most cases it emitted an error message:
“snprintf failed when trying to build auth string”
Thanks to Joerg Heinemann for alerting us.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=404 - bugfix: some property-based filter were incorrectly parsed
This usually lead to a syntax error on startup and rsyslogd not actually starting up. The problem was the regex, which did not care for double quote characters to follow in the action part – unfortunately something that can frequently happen with v6+ format. An example:
:programname, isequal, “as” {action(type=”omfile” …) }
Here, the part
:programname, isequal, “as” {action(type=”omfile”
was treated as the property filter, and the rest as action part. Obviously, this did not work out. Unfortunately, such situations usually resulted in very hard to understand error messages.
How can I check the config?
We have often seen the case, that someone has rsyslog running and makes changes to the configuration. And usually, after making the changes, rsyslog gets restarted, but the changed config is invalid. rsyslog has a function to check the configuration for validity. This can be done very easily by invoking this command:
rsyslogd -N1
(Note that rsyslogd may not be in your search path – then it usually is found in /sbin/rsyslogd)
This tells rsyslog to do a config check. It does NOT run in regular mode, but just check configuration file correctness. This option is meant to verify a config file. To do so, run rsyslogd interactively in foreground, specifying -f <config-file> and -N level. The level argument modifies behaviour. Currently, 0 is the same as not specifying the -N option at all (so this makes limited sense) and 1 actually activates the code.
This configuration check will only check the configuration for integrity like syntax. Additionaly, the modules will be loaded to make sure that they work properly. On the downside, since the engine will not be loaded, errors with permissions or alike cannot be checked. These will occur only when running rsyslog normally.
The verdict for this option is, that it is quite useful for a first check if the changes were correct, without running the configuration in live mode. This might help to prevent that rsyslog gets restarted with a basically wrong configuration and thus rendering rsyslog useless, because it might not work or not work properly.
Changelog for 7.3.6 (v7-devel)
Version 7.3.6 [devel] 2013-01-28
- greatly improved speed of large-array [N]EQ RainerScript comparisons
Thanks to David Lang for a related discussion that inspired the idea
to do this with a much simpler (yet sufficient) approach than orignally
planned for. - greatly improved speed of DNS cache for large cache sizes
- general performance improvements
- omfile: added stats counters for dynafile caches
- omfile: improved async writing, finally enabled full async write
also fixed a couple of smaller issues along that way - impstats: added ability to write stats records to local file
and avoid going through the syslog log stream. syslog logging can now
also be turned off (see doc for details). - bugfix: imklog issued wrong facility in error messages
…what could lead to problems in other parts of the code - fix compile problem in imklog
- added capability to output thread-id-to-function debug info
This is a useful debug aid, but nothing of concern for regular users.
Filter optimization with arrays
If you are using a lot of filters and templates in rsyslog, this can not only be affecting the performance drastically, but it is also a hassle to set up all the different actions and templates. It is always worthy to check, if there isn’t a shortcut somewhere, which might not only save you time for creating the configuration, but also make it much simpler in the end to keep track of all the actions.
In our example, we have several programnames. The log messages should be sorted by programname and then be stored in a specific file and be sorted by host. After storing the log messages, the message should be discarded, so it won’t be processed by the following filters, thus saving otherwise wasted processing time. This example is applicable to rsyslog v7.2.x and above.
Here are some sample config lines.
## apache_access
template(name="DailyPerHost_apache_access" type="string" string="/syslog/%FROMHOST%/apache_access.log")
:programname, isequal, "apache_access" { action(type="omfile" DynaFile="DailyPerHost_apache_access") stop }
## apache_error
template(name="DailyPerHost_apache_error" type="string" string="/syslog/%FROMHOST%/apache_error.log")
:programname, isequal, "apache_error" { action(type="omfile" DynaFile="DailyPerHost_apache_error") stop }## mysql
template(name="DailyPerHost_mysql" type="string" string="/syslog/%FROMHOST%/mysql.log")
:programname, isequal, "mysql" { action(type="omfile" DynaFile="DailyPerHost_mysql") stop }
## php
template(name="DailyPerHost_php" type="string" string="/syslog/%FROMHOST%/php.log")
:programname, isequal, "php" { action(type="omfile" DynaFile="DailyPerHost_php") stop }These are some basic services, which are often run together. Please note, that these are just a few examples. As you can see here, the template is created first. It is given a name, type and format. Templates of type string are usually used for file names. Here the log messages get stored in the folder /syslog a subfolder for the host where the message occured and then a filename which reflects the type of message that occured.
The second line holds the actions. First you see the property based filter (programname) and the condition. After that the actions get chained with the curly braces. The log messages where the filter evaluates to true get stored in a file. The filename and path is generated dynamically with the DynaFile parameter. Through this, the above written template will be used to generate the path and filename. The second action is represented by stop. Please note that this is case sensitive. Basically, stop means to stop the message processing. No further processing of the message will take place.
If we look closely at the sample config lines, we see, that the filter condition is basically always the same. It will always filter the programname property for a certain value. This is a predestinated case for using an array for simplification. We can use the property programname in the file template as well and filter an array of values. This will greatly save the overhead for all the seperate filter, not only in the configuration, but also in processing the messages.
template(name="DailyPerHost_app" type="string" string="/syslog/%FROMHOST%/%programname%.log")
if $programname == ["apache_access",
"apache_error",
"mysql",
"php"]
then {
action(type="omfile" DynaFile="DailyPerHost_app")
stop
}Again, we first create the template. Please note the difference in the filename where the hardcoded text has been replaced by the property programname. In the next lines, we see the filter and the array of values. This is just to reflect the example. Virtually, the array can have near-infinite values. The filter is also a common if/then construct. After the then we see our chain of commands. First the action which writes the log messages into a file where the filename is created by the above template and then a stop as second action.
This case is applicable in many forms. It is also most useful if you are filtering and the discarding a lot of messages with very common filter settings. You could use it to filter for an array of property values and even chain comparison operations.
Changelog for 7.2.5 (v7-stable)
Version 7.2.5 [v7-stable] 2013-01-08
- build system cleanup (thanks to Michael Biebl for this!)
- bugfix: omelasticsearch did not properly compile on some platforms due to missing libmath. Thanks to Michael Biebl for the fix
- bugfix: invalid DST handling under Solaris
Thanks to Scott Severtson for the patch. - bugfix: on termination, actions were incorrectly called
The problem was that incomplete fiter evaluation was done *during the shutdown phase*. This affected only the LAST batches being processed. No problem existed during the regular run. Could usually only happen on very busy systems, which were still busy during shutdown. - bugfix: very large memory consumption (and probably out of memory) when FromPos was specified in template, but ToPos not.
Thanks to Radu Gheorghe for alerting us of this bug. - bugfix: timeval2syslogTime cause problems on some platforms due to invalid assumption on structure data types.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=394
Thanks to David Hill for the patch [under ASL2.0 as per email conversation 2013-01-03]. - bugfix: compile errors in im3195
Thanks to Martin Körper for the patch - bugfix: doGetFileCreateMode() had invalid validity check ;)
Thanks to Chandler Latour for the patch. - bugfix: mmjsonparse errornously returned action error when no CEE cookie was present.
Changelog for 7.3.5 (v7-devel)
Version 7.3.5 [devel] 2012-12-19
- ommysql: addded batching/transaction support
- enhanced script optimizer to optimize common PRI-based comparisons
These constructs are especially used in SUSE default config files,
but also by many users (as they are more readable than the equivalent
PRI-based filter). - omudpspoof: add support for new config system
- omudpspoof: add support for packets larger than 1472 bytes
On Ethernet, they need to be transmitted in multiple fragments. While
it is known that fragmentation can cause issues, it is the best choice
to be made in that case. Also improved debug output. - bugfix: omudpspoof failed depending on the execution environment
The v7 engine closes fds, and closed some of libnet’s fds as well, what
lead to problems (unfortunately, at least some libnet versions do not
report a proper error state but still “success”…). The order of libnet
calls has been adjusted to by in sync with what the core engine does. - bugfix: segfault on imuxsock startup if system log socket is used
and no ratelimiting supported. Happens only during initial config
read phase, once this is over, everything works stable. - bugfix: mmnormalize build problems
- bugfix: mmnormalize could abort rsyslog if config parameter was in error
- bugfix: no error message for invalid string template parameters
rather a malformed template was generated, and error information emitted
at runtime. However, this could be quite confusing. Note that with this
“bugfix” user experience changes: formerly, rsyslog and the affected
actions properly started up, but the actions did not produce proper
data. Now, there are startup error messages and the actions are NOT
executed (due to missing template due to template error). - bugfix[minor]: invalid error code when mmnormalize could not access rulebase
- bugfix(kind of): script optimizer did not work for complex boolean expressions
- doc bugfix: corrections and improvements in mmnormalize html doc page
- bugfix: some message properties could be garbled due to race condition
This happened only on very high volume systems, if the same message was
being processed by two different actions. This was a regression caused
by the new config processor, which did no longer properly enable msg
locking in multithreaded cases. The bugfix is actually a refactoring of
the msg locking code – we no longer do unlocked operations, as the use
case for it has mostly gone away. It is potentially possible only at
very low-end systems, and there the small additional overhead of doing
the locking does not really hurt. Instead, the removal of that
capability can actually slightly improve performance in common cases,
as the code path is smaller and requires slightly less memory writes.
That probably outperforms the extra locking overhead (which in the
low-end case always happens in user space, without need for kernel
support as we can always directly aquire the lock – there is no
contention at all). - build system cleanup (thanks to Michael Biebl for this!)
- bugfix: omelasticsearch did not properly compile on some platforms
due to missing libmath. Thanks to Michael Biebl for the fix.
Version support policy change
We will be changing our policy so that only the latest stable build will be officially supported. This is done in an effort to concentrate resouces on building new and great things, instead of wasting a lot of time merging from old versions. A lot of -competing- projects have this policy and thus can move faster. We don’t want to carry that disadvantage any further with us.
For folks with support contracts, of course nothing changes: we always supported all versions – no matter how old – under these contracts (as long as technically possible). Please also note that we always consider older, but frequently used versions when it comes to important bug fixes (for example, I lately added a couple of fixes to v5.10, which is no longer officially supported for quite a while).
I would like to point out that rsyslog has a very considerate version management, with keeping major versions in different branches and (via professional support) taking care of each old version. This enterprise release scheme is under no discussion.
As a side-note: the discussion was started when I thought about non-critical fixes that I did for v7 and we thought about if it really makes sense to spend time to backport them to v6. There are also some enhancement-like “bugfixes” (like better config error messages), which will stay with the devel branch and mature into the next stable (if for nothing else, than for their regression potential).
Best regards,
Rainer Gerhards
Changelog for 7.3.4 (v7-devel)
Version 7.3.4 [devel] 2012-11-23
- further (and rather drastically) improved disk queue performance
we now save one third of the IO calls - imklog: added ParseKernelTimestamp parameter (import from 5.10.2)
Thanks to Marius Tomaschewski for the patch. - imklog: added KeepKernelTimestamp parameter (import from 5.10.2)
Thanks to Marius Tomaschewski for the patch. - bugfix: improper handling of backslash in string-type template()s
- bugfix: leading quote (“) in string-type template() lead to thight loop
on startup - bugfix: no error msg on invalid field option in legacy/string template
- bugfix: imklog mistakenly took kernel timestamp subseconds as nanoseconds
… actually, they are microseconds. So the fractional part of the
timestamp was not properly formatted. (import from 5.10.2)
Thanks to Marius Tomaschewski for the bug report and the patch idea.
Changelog for 7.2.3 (v7-stable)
Version 7.2.3 [v7-stable] 2012-11-21
- regression fix: rsyslogd terminated when wild-card $IncludeConfig did not
find actual include files. For example, if this directive is present:
$IncludeConfig /etc/rsyslog.d/*.conf
and there are no *.conf files in /etc/rsyslog.d (but rsyslog.d exists),
rsyslogd will emit an error message and terminate. Previous (and expected)
behaviour is that an empty file set is no problem. HOWEVER, if the
directory itself does not exist, this is flagged as an error and will
load to termination (no startup).
Unfortunately, this is often the case by default in many distros, so this
actually prevents rsyslog startup.
