[ZBX-24340] New Regular Expression Error with logrt Created: 2024 Apr 11  Updated: 2024 Jun 19

Status: Need info
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G)
Affects Version/s: 6.4.13
Fix Version/s: None

Type: Problem report Priority: Trivial
Reporter: David Otero Assignee: Karlis Salins
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server: Debian 12.
Agent 2 (active): Windows 11.


Attachments: PNG File With_Escaped_L.png     PNG File With_error_description-1.png     PNG File With_error_description.png     PNG File Without_error_description.png     Text File log.txt    

 Description   

I've been using the following regular expression in logrt to specify the log file without any issues for several weeks:

Code:
logrt[C:\Programas\3. Version DEBUG PalStats con Grafico\Logs\Actual\^\d\{4}-\d\{2}-\d\{2}_\d\{2}-\d\{2}-\d\{2}\.log,"ERROR",,,"skip",]
However, today, unexpectedly, I encountered an error with this item stating:

"Cannot compile a regular expression describing filename pattern: PCRE2 does not support \F, \L, \l, \N{name}, \U, or \u, position 39, flags:0x2400".

Enclosing the directory path in quotes does not resolve the issue. I haven't come across any updates that might have impacted this behavior. Does anyone have an idea what could be causing this?

It seems that even if all the "-s" are escaped to "
-s", it still doesn't work: it indicates that regular expressions cannot be used in the path route.

However, if I only escape "
Logs" in the path, the corresponding item in Zabbix transitions to an "enabled" state without showing any errors. However, it fails to capture the expected logs values. 

**

logrt[C:\Programas\3. Version DEBUG PalStats con Grafico\\Logs\Actual\^\d{4}-\d{2}-\d{2}_\d{2}-\d{2}-\d{2}\.log,"ERROR",,,"skip",]

**
It's a bit counterintuitive. It seems that in a minor release, someone wanted to improve the debugger by searching for \F, \L, \l, \N{name}, \U, or \u throughout the entire path, forgetting that regular expressions can only be used in the filename.

 

Thanks.



 Comments   
Comment by Karlis Salins [ 2024 Apr 30 ]

Hello.
Thank you for reaching out to us.
I could not reproduce the issue listed.
Can you please add a screenshot of the item as well as the unsupported error message?
Please also attach agent log file.

Best regards,
Karlis

Comment by David Otero [ 2024 Apr 30 ]

Thanks for the response.

  • Screenshot (A): it worked before, now it doesn´t.

  • Screenshot (B): it worked before, now it doesn´t, with error description (seems to treat directory as regular expression):

  • Screenshot (C): it doesn´t really work, although it is enabled by escaping "
    L" and it stops giving an error.

 

I attach the agent log (after "C:\" seems treat all like filename).

log.txt

Thanks for the work.

Generated at Mon May 05 07:34:57 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.