New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mmnormalize_{variable,tokenized,regex}.sh tests are failing #489
Comments
OK, this is a problem which only happens with liblognorm-1.1.2. It is working fine with liblognorm-1.1.1. Do we need to mask liblognorm-1.1.2 for rsyslog or does the test requires an update to work with liblognorm-1.1.2? |
I will look into this. |
Are you certain these tests worked with liblognorm-1.1.1? |
100% sure. I just verified again:
If you could bring back 1.1.1 for precise in the ppa Travis would pass, too (when we would pin the package to 1.1.1). |
I think this problem is related to this issue here: rsyslog/liblognorm#57 Maybe the tests in rsyslog also just need to be updated, maybe there indeed was a problem that neither @janmejay nor me noticed after the initial discussion. |
Breaks rsyslog. See http://lists.adiscon.net/pipermail/rsyslog/2015-August/041013.html rsyslog/rsyslog#489 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
I have probably traced the problem down to the root cause: the testbench generates rulebases with incomplete lines (\n missing). As it looks, the new liblognorm code does not accept such incomplete lines, but the old one seemed to process them. I'll dig into it some more, but thought I share the news (I need to continue tomorrow). |
This problem occurs with the very last line of a rulebase (at EOF). If it is not properly terminated (LF missing), it is silently ignored. Previous versions did obviously process lines in this case. While technically this is invalid input, we can't outrule that such rulebases exist. For example, they do in the rsyslog testbench, which made us aware of the problem (see rsyslog/rsyslog#489 ). I think the proper way of addressing this is to process such lines without termination, as many other tools do as well.
This problem occurs with the very last line of a rulebase (at EOF). If it is not properly terminated (LF missing), it is silently ignored. Previous versions did obviously process lines in this case. While technically this is invalid input, we can't outrule that such rulebases exist. For example, they do in the rsyslog testbench, which made us aware of the problem (see rsyslog/rsyslog#489 ). I think the proper way of addressing this is to process such lines without termination, as many other tools do as well. closes rsyslog#135
This problem occurs with the very last line of a rulebase (at EOF). If it is not properly terminated (LF missing), it is silently ignored. Previous versions did obviously process lines in this case. While technically this is invalid input, we can't outrule that such rulebases exist. For example, they do in the rsyslog testbench, which made us aware of the problem (see rsyslog/rsyslog#489 ). I think the proper way of addressing this is to process such lines without termination, as many other tools do as well. closes rsyslog#135
This problem occurs with the very last line of a rulebase (at EOF). If it is not properly terminated (LF missing), it is silently ignored. Previous versions did obviously process lines in this case. While technically this is invalid input, we can't outrule that such rulebases exist. For example, they do in the rsyslog testbench, which made us aware of the problem (see rsyslog/rsyslog#489 ). I think the proper way of addressing this is to process such lines without termination, as many other tools do as well. closes rsyslog#135
These tests (plus two not mentioned) now work with the new version of liblognorm, with the exception of the _regex test. It looks like this test does something wrong, the root cause is that it tests regex when it is not supported. Will look into it, but may wait until @janmejay has time to dig further. |
Rainer, I'm buried in work add of now, I may take at least a few weeks Regards, PS: Please blame the typos in this mail on my phone's uncivilized soft On Aug 24, 2015 2:58 PM, "Rainer Gerhards" notifications@github.com wrote:
|
Sent from phone, thus brief.
No Problem. If i don't see it quickly enough, I'll comment out the test. Rainer
|
@janmejay as it looks, at least in travis the regex test works now. I still have problems in one environment, may be environment-induced. I would appreciate if you could look into the issue when you have time later. Note that I am not yet sure if we should support regex in v2 natively, so this may become a non-issue within the next few weeks. |
I think its valuable to support regexp for odd unforeseen cases. I'll On Tue, Aug 25, 2015 at 1:32 PM, Rainer Gerhards notifications@github.com
Regards, |
@janmejay I opened an issue tracker where we can discuss the need to re-introduce regex: rsyslog/liblognorm#143 |
Sounds good. On Thu, Aug 27, 2015 at 12:25 PM, Rainer Gerhards notifications@github.com
Regards, |
…issue #135 This fix is required to pass rsyslog's test suite, see rsyslog/rsyslog#489
Short update: We disabled PCRE in liblognorm-1.1.2 like suggested in rsyslog/liblognorm#143 and cherry-picked rgerhards/liblognorm@4b35ca1 which fixed the issue for the remaining two tests mmnormalize_variable.sh and mmnormalize_tokenized.sh. Now that rsyslog-8.13.0 finally passed the test suite on all our supported plattforms we added it to the tree. Not sure if this issue should stay open until rsyslog requirements for liblognorm are bumped to require a version with the patch included or not so people experiencing the same problem will find it (and a solution). |
As it looks, this is solved. I do also see no related failures in our CI runs. If the problem re-occurs, let me know and I can re-open. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
The
tests are failing:
Confirmed against rsyslog-8.12.0 release tarball and git at 1e26405.
The text was updated successfully, but these errors were encountered: