2.0.0p3 CEE - Pattern Matching Bug

Hey, everyone.

Just completed the update to 2.0.0p3 from 1.6.0p22 yesterday. It seems there is a bug in the pattern matching for Logwatch. Since implementation, all the rules I have added for preventing noisy logs from making it to my screen have functioned flawlessly. Now, however, it seems those rules have stopped processing and I’m seeing messages that haven’t appeared in over a year.

Items like this:

Apr 30 08:52:20 0.10016 DCOM machine-default Local Activation {C2F03A33-21F5-47FA-B4BB-156362A2F239} {316CDED5-E4AE-4B15-9113-7055D84DCC97} —removed— S-1-5-21-2996461673-2147617008-1360542531-1168 LocalHost (Using LRPC) Microsoft.Windows.ShellExperienceHost_10.0.19041.610_neutral_neutral_cw5n1h2txyewy S-1-15-2-155514346-2573954481-755741238-1654018636-1233331829-3075935687-2861478708

and:

Apr 30 09:08:15 32768.5014 DFSR The DFS Replication service is stopping communication with partner —removed— for replication group Domain System Volume due to an error. The service will retry the connection periodically. Additional Information: Error: 9036 (Paused for backup or restore) Connection ID: 14B84E5D-3B6B-4F66-8552-9E35941B6F77 Replication Group ID: 95B7D05D-180D-41CE-8EC4-91A5273219BB

Used to match and be Ignored with no issues. Now, however, those logs are now appearing as WARN in CMK. If I click the Analyze Patterns button they still show as matching, but yet they continue to appear as WARN.

Any help to fix would be greatly appreciated.

Thanks,
Tralin

It’s difficult to reproduce this without any configuration examples. How does the rule look like that matched before?

Hey, _rb.

Just a couple examples that are on screen right now:

Apr 30 09:20:11 0.10016 DCOM machine-default Local Activation {C2F03A33-21F5-47FA-B4BB-156362A2F239} {316CDED5-E4AE-4B15-9113-7055D84DCC97} —removed— S-1-5-21-2996461673-2147617008-1360542531-1168 LocalHost (Using LRPC) Microsoft.Windows.ShellExperienceHost_10.0.19041.610_neutral_neutral_cw5n1h2txyewy S-1-15-2-155514346-2573954481-755741238-1654018636-1233331829-3075935687-2861478708

Matches an Ignore rule:

DCOM machine-default Local Activation {C2F03A33-21F5-47FA-B4BB-156362A2F239}

Another one:

Apr 30 11:52:31 0.10016 DCOM application-specific Local Activation {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54} {15C20B67-12E7-4BB6-92BB-7AFF07997402} —removed— S-1-5-21-2996461673-2147617008-1360542531-1219 LocalHost (Using LRPC) Unavailable Unavailable

Matches an Ignore rule:

DCOM application-specific Local Activation {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}

I can send others as they come back up in CMK.

Thanks,
Tralin

Edit: There are backslashes in front of the { and } characters, but the forum removed them, it seems.

I can confirm that every character what is escaped with an “\” lead to a non working logwatch pattern matching.
In one of my systems I had some pattern with [ and ]. These where escaped with one \ but CMK saves this rule with two \
Original rule

some test \[ABCD\]

Saved as

some test \\[ABCD\\]

Don’t know if this is the reason, that way the rules are stored at least since 1.6.0.

Maybe a problem of processing such pattern. We will have a look at this next week

That was not my expectation that someone is doing anything this holiday weekend :smiley:

Hey, guys.

Glad the issue is repeatable. For us at least, it’s a non-critical item. Feel free to defer this until a more convenient time.

Have a great weekend!
Tralin

It appears that for unknown reasons logwatch escapes all backslashes just before using the pattern.

Patching it like this seems to fix the problem (tested with 2.0.0p3 raw edition):

--- a/lib/python3/cmk/base/plugins/agent_based/utils/logwatch.py	2021-04-17 15:31:34.000000000 +0200
+++ b/lib/python3/cmk/base/plugins/agent_based/utils/logwatch.py	2021-04-30 22:34:04.123492955 +0200
@@ -98,7 +98,7 @@
     # Reclassify state if a given regex pattern matches
     # A match overrules the previous state->state reclassification
     for level, pattern, _ in patterns.get("reclassify_patterns", []):
-        reg = regex(escape_win_backslash(pattern), re.UNICODE)
+        reg = regex(pattern, re.UNICODE)
         if reg.search(text):
             # If the level is not fixed like 'C' or 'W' but a pair like (10, 20),
             # then we count how many times this pattern has already matched and
1 Like

This should already been fixed with werk #12631 in 2.0.0p4 (released soon) even the problem described in that werk is another one.

1 Like