summaryrefslogtreecommitdiffstats
path: root/ChangeLog
Commit message (Collapse)AuthorAgeFilesLines
* added bug info to ChangeLogRainer Gerhards2011-08-301-2/+3
|
* Added MsgDup bugfix from v5-stable into v4-stable branchAndre Lorbach2011-08-111-0/+1
|
* bugfix: memcpy overflow can occur in allowed sender checkingMarius Tomaschewski2011-08-091-0/+3
| | | | | | | ...if a host name is resolved to IPv4-mapped-on-IPv6 address. Found by Ismail Dönmez at suse. Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* Merge branch 'v3-stable' into v4-stableAndre Lorbach2011-08-051-0/+4
|\ | | | | | | | | | | Conflicts: runtime/msg.c
| * bugfix: potential misadressing in property replacerAndre Lorbach2011-08-051-0/+1
| |
* | preparing for 4.6.7 releasev4.6.7Rainer Gerhards2011-07-111-1/+2
| |
* | added support for the ":omusrmsg:" syntax in configuring user messagesRainer Gerhards2011-07-061-0/+3
| |
* | preparing for 4.6.6v4.6.6Rainer Gerhards2011-06-241-1/+1
| |
* | Merge branch 'v3-stable' into v4-stableRainer Gerhards2011-06-161-0/+6
|\| | | | | | | | | Conflicts: runtime/datetime.c
| * bugfix: timestamp was incorrectly calculated for timezones with minute offsetRainer Gerhards2011-06-161-0/+3
| | | | | | | | closes: http://bugzilla.adiscon.com/show_bug.cgi?id=271
* | bugfix: memory leak in imtcp & subsystems under some circumstancesRainer Gerhards2011-06-141-0/+3
| | | | | | | | | | This leak is tied to error conditions which lead to incorrect cleanup of some data structures. [backport from v6, limited testing under v4]
* | bugfix: invalid processing in QUEUE_FULL conditionRainer Gerhards2011-05-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | If the the multi-submit interface was used and a QUEUE_FULL condition occured, the failed message was properly destructed. However, the rest of the input batch, if it existed, was not processed. So this lead to potential loss of messages and a memory leak. The potential loss of messages was IMHO minor, because they would have been dropped in most cases due to the queue remaining full, but very few lucky ones from the batch may have made it. Anyhow, this has now been changed so that the rest of the batch is properly tried to be enqueued and, if not possible, destructed.
* | bugfix: invalid storage type for config variablesRainer Gerhards2011-05-091-0/+1
| |
* | bugfix: stream driver mode was not correctly set on tcp ouput on big endian ↵Tomas Heinrich2011-05-091-0/+3
| | | | | | | | | | | | systems. Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* | bugfix: memory and file descriptor leak in stream processingRainer Gerhards2011-05-031-0/+6
| | | | | | | | | | | | | | | | Leaks could occur under some circumstances if the file stream handler errored out during the open call. Among others, this could cause very big memory leaks if there were a problem with unreadable disk queue files. In regard to the memory leak, this closes: http://bugzilla.adiscon.com/show_bug.cgi?id=256
* | bugfix: TCP connection invalidly aborted when messages needed to be discardedRainer Gerhards2011-05-021-0/+2
| | | | | | | | due to QUEUE_FULL or similar problem
* | slightly more informative errmsg when TCP connection is abortedRainer Gerhards2011-05-021-0/+2
| |
* | bugfix: IPv6-address could not be specified in omrelpRainer Gerhards2011-04-141-0/+3
| | | | | | | | | | this was due to improper parsing of ":" closes: http://bugzilla.adiscon.com/show_bug.cgi?id=250
* | bugfix: omlibdbi did not use password from rsyslog.conRainer Gerhards2011-03-091-0/+2
| | | | | | | | closes: http://bugzilla.adiscon.com/show_bug.cgi?id=203
* | bugfix: abort if imfile reads file line of more than 64KiBRainer Gerhards2011-02-101-0/+3
| | | | | | | | | | Thanks to Peter Eisentraut for reporting and analysing this problem. bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=221
* | imfile bugfix: potential duplication of log contentRainer Gerhards2011-01-101-0/+3
| | | | | | | | | | | | Under some circumstances an invalid truncation was detected. This code has now been removed, a file change (and thus resent) is only detected if the inode number changes.
* | bugfix: imfile potentially duplicates linesRainer Gerhards2010-12-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This can happen when 0 bytes are read from the input file, and some writer appends data to the file BEFORE we check if a rollover happens. The check for rollover uses the inode and size as a criterion. So far, we checked for equality of sizes, which is not given in this scenario, but that does not indicate a rollover. From the source code comments: Note that when we check the size, we MUST NOT check for equality. The reason is that the file may have been written right after we did try to read (so the file size has increased). That is NOT in indicator of a rollover (this is an actual bug scenario we experienced). So we need to check if the new size is smaller than what we already have seen!
* | some cleanup based on clang static analyzer resultsRainer Gerhards2010-12-161-0/+4
| |
* | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-12-161-0/+3
|\| | | | | | | | | Conflicts: ChangeLog
| * improved some code based on clang static analyzer resultsRainer Gerhards2010-12-161-0/+3
| |
* | Merge branch 'v4.4.2a' into v4-stableRainer Gerhards2010-11-251-5/+7
|\ \ | | | | | | | | | | | | | | | | | | | | | Conflicts: ChangeLog configure.ac plugins/imfile/imfile.c runtime/stream.c
| * | bugfix: a couple of problems that imfile had on some platformsRainer Gerhards2010-10-151-0/+2
| | | | | | | | | | | | namely Ubuntu (not their fault, but occured there)
| * | bugfix: imfile utilizes 32 bit to track offsetRainer Gerhards2010-10-151-0/+5
| | | | | | | | | | | | | | | Most importantly, this problem can not experienced on recent Fedora 64 bit OS (which has 64 bit long's!)
* | | final preparations for releasev4.6.5Rainer Gerhards2010-11-241-1/+1
| | |
* | | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-11-241-0/+10
|\ \ \ | | |/ | |/| | | | | | | | | | Conflicts: ChangeLog configure.ac
| * | bugfix(important): problem in TLS handling could cause rsyslog to loopv3.22.3Rainer Gerhards2010-11-241-0/+6
| | | | | | | | | | | | | | | | | | ... in a tight loop, effectively disabling functionality and bearing the risk of unresponsiveness of the whole system. Bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=194
* | | imfile: bugfixes in regard to large files (> 2GB)Rainer Gerhards2010-10-151-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | - bugfix: a couple of problems that imfile had on some platforms, namely Ubuntu (not their fault, but occured there) - bugfix: imfile utilizes 32 bit to track offset. Most importantly, this problem can not experienced on Fedora 64 bit OS (which has 64 bit long's!)
* | | preparing for 4.6.4v4.6.4Rainer Gerhards2010-08-051-1/+1
| | |
* | | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-08-051-1/+1
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: ChangeLog configure.ac doc/manual.html doc/professional_support.html
| * | preparing for 3.22.2v3.22.2Rainer Gerhards2010-08-051-1/+1
| | |
* | | Merge branch 'v3-stable' into v4-stableRainer Gerhards2010-08-051-0/+4
|\| | | | | | | | | | | | | | Conflicts: runtime/conf.c
| * | program name filter ! in the configuration cannot be resetKiss Gabor (Bitman)2010-08-051-0/+2
| | | | | | | | | | | | Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* | | bugfix: zero-sized (empty) messages were processed by imtcpRainer Gerhards2010-07-281-0/+2
| | | | | | | | | | | | they are now dropped as they always should have been
* | | bumped version numberRainer Gerhards2010-07-071-0/+2
| | |
* | | preparing for 4.6.3v4.6.3Rainer Gerhards2010-07-071-1/+1
| | |
* | | bugfix: segfault on HUP when "HUPIsRestart" was set to "on"varmojfekoj2010-07-051-0/+2
| | | | | | | | | | | | Signed-off-by: Rainer Gerhards <rgerhards@adiscon.com>
* | | some doc fixes; incorrect config samples could cause confusionRainer Gerhards2010-05-201-0/+2
| | | | | | | | | | | | thanks to Anthony Edwards for pointing the problems out
* | | added new configure option that permits to disable and enable an extended ↵Rainer Gerhards2010-04-121-0/+4
| | | | | | | | | | | | testbench
* | | bugfix: default for $OMFileFlushOnTXEnd was wrong ("off").Rainer Gerhards2010-04-071-0/+4
| | | | | | | | | | | | | | | | | | This, in default mode, caused buffered writing to be used, what means that it looked like no output were written or partial lines. Thanks to Michael Biebl for pointing out this bug.
* | | improvded testbench: added test with truly random data received via syslog ↵Rainer Gerhards2010-04-011-0/+3
| | | | | | | | | | | | to test robustness
* | | temporary bugfix replaced by permanent one for...Rainer Gerhards2010-03-311-0/+4
| | | | | | | | | | | | | | | | | | ...message-induced off-by-one error (potential segfault) (see 4.6.2) The analysis has been completed and a better fix been crafted and integrated.
* | | bugfix: testbench failed when not executed in UTC+1 timezoneRainer Gerhards2010-03-291-0/+3
| | | | | | | | | | | | | | | accidently, the time zone information was kept inside some to-be-checked-for responses
* | | preparing for 4.6.2v4.6.2Rainer Gerhards2010-03-261-1/+1
| | |
* | | new feature: $OMFileAsyncWriting directive addedRainer Gerhards2010-03-251-0/+2
| | | | | | | | | | | | it permits to specifiy if asynchronous writing should be done or not
* | | bugfix(temporary): message-induced off-by-one error (potential segfault)Rainer Gerhards2010-03-251-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some types of malformed messages could trigger an off-by-one error (for example, \0 or \n as the last character, and generally control character escaption is questionable). This is due to not strictly following a the \0 or string counted string paradigm (during the last optimization on the cstring class). As a temporary fix, we have introduced a proper recalculation of the size. However, a final patch is expected in the future. See bug tracker for further details and when the final patch will be available: http://bugzilla.adiscon.com/show_bug.cgi?id=184 Note that the current patch is considered sufficient to solve the situation, but it requires a bit more runtime than desirable.