[ZBX-9507] log item stuck at "Not Supported" Created: 2015 Apr 22  Updated: 2017 May 30  Resolved: 2015 Apr 23

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G), Server (S)
Affects Version/s: 2.4.4
Fix Version/s: None

Type: Incident report Priority: Minor
Reporter: stephen boyle Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: logmonitoring
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

2.4.4 Server on CentOS, 2.4.4 Agents on Mac OS X

Issue Links:
Duplicate
duplicates ZBXNEXT-444 Improvement processing of event logs ... Closed

 Description   

Having an issue with 2.4.4 in which a log monitor item seems to get into a "Not Supported" state. The logic of the Item is correct - and the only way i am able to get it to fix itself is to actually delete the log Item, wait until housekeeping occurs, and then re-create the item.

I have posted details in a forum post including agent debug log entries. This work-around works for now.

forum post:
https://www.zabbix.com/forum/showthread.php?p=165455

 Comments   
Comment by stephen boyle [ 2015 Apr 22 ]

agent debug log:

20303:20150417:155408.357 active checks #1 [processing active checks]
20303:20150417:155408.357 In process_active_checks() server:'zabbix.trmacs.com' port:10051)
20303:20150417:155408.357 In process_logrt() is_logrt:0 filename:'/private/var/log/system.log' lastlogsize:1222923 mtime:0 error_count:0
20303:20150417:155408.357 In add_logfile() filename:'/private/var/log/system.log' mtime:1429300434 size:1223431
20303:20150417:155408.357 add_logfile() logfiles:0x104000000 logfiles_alloc:64
20303:20150417:155408.357 End of add_logfile()
20303:20150417:155408.357 setup_old2new: is_same_file(/private/var/log/system.log, /private/var/log/system.log) = 1
20303:20150417:155408.357 process_logrt() old file list:
20303:20150417:155408.358 nr:0 filename:'/private/var/log/system.log' mtime:1429300414 size:1222923 processed_size:1222923 seq:1 incomplete:0 dev:16777218 ino_hi:0 ino_lo:20994147 md5size:512 md5buf:35e6c9df64be630536e7e593d54aa72e
20303:20150417:155408.358 process_logrt() new file list: (mtime:0 lastlogsize:1222923 start_idx:0)
20303:20150417:155408.358 nr:0 filename:'/private/var/log/system.log' mtime:1429300434 size:1223431 processed_size:1222923 seq:0 incomplete:0 dev:16777218 ino_hi:0 ino_lo:20994147 md5size:512 md5buf:35e6c9df64be630536e7e593d54aa72e
20303:20150417:155408.358 In process_log() filename:'/private/var/log/system.log' lastlogsize:1222923 mtime: 0
20303:20150417:155408.358 End of process_log() filename:'/private/var/log/system.log' lastlogsize:1223431 mtime: 0 ret:SUCCEED
20303:20150417:155408.358 End of process_logrt():SUCCEED error_count:0
20303:20150417:155408.358 End of process_active_checks()
20303:20150417:155408.358 In get_min_nextcheck()

Comment by Aleksandrs Saveljevs [ 2015 Apr 23 ]

According to the forum thread, you use the following item:

log[{$KERNEL_LOG},"I/O error"]

According to ZBXNEXT-444, if the item becomes not supported, then it will only become supported again if there is line containing "I/O error". Until that time, the item will stay not supported (even if the file can be read), and this is what ZBXNEXT-444 deals with. So currently it is proposed to close this issue as a duplicate of ZBXNEXT-444, unless you have a different scenario.

Comment by stephen boyle [ 2015 Apr 23 ]

was unable to find that other documented issue. while i have not tested adding the string to the log file to see if it ends up becoming supported again this makes sense and i do not think this is a different scenario. thanks - this appears to be a duplicate.

Generated at Sat Apr 27 06:29:17 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.