[ZBX-4480] using "Interfaces" as Application name makes the host unavailable Created: 2011 Dec 22  Updated: 2017 May 30  Resolved: 2012 Apr 17

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 1.9.8 (beta)
Fix Version/s: None

Type: Incident report Priority: Major
Reporter: Marc Herren Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: items, snmp
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS Linux release 6.0 (Final)


Attachments: PNG File Screen Shot 2011-12-22 at 5.38.40 PM.png    
Issue Links:
Duplicate
duplicates ZBX-4425 When update item interface is set to ... Closed

 Description   

I have configured a host with SNMP observing several SNMP values.

As soon as I create an Application named "Interfaces" the previous working snmp request stops working.

The server.log shows:

18793:20111222:173250.415 SNMP item [Port_22_In_Octets] on host [test] failed: first network error, wait for 15 seconds
18791:20111222:173251.413 SNMP item [Port_22_Out_Octets] on host [test] failed: another network error, wait for 15 seconds
18795:20111222:173252.418 SNMP item [Port_22_In_Errors] on host [test] failed: another network error, wait for 15 seconds
18794:20111222:173253.428 SNMP item [Port_22_Out_Errors] on host [test] failed: another network error, wait for 15 seconds
18796:20111222:173314.066 SNMP item [Port_22_Out_Octets] on host [test] failed: another network error, wait for 15 seconds
18796:20111222:173335.086 SNMP item [Port_22_Out_Errors] on host [test] failed: another network error, wait for 15 seconds
18796:20111222:173356.119 temporarily disabling SNMP checks on host [test]: host unavailable
18796:20111222:173456.128 enabling SNMP checks on host [test]: host became available

I then have to completely remove the host from the db and recreate it. Just removing the Application association does not help.

Without having this association SNMP retrieval works without any issue.



 Comments   
Comment by Marc Herren [ 2011 Dec 22 ]

it works without any problems with other appliction names, only "Interfaces" is causing problems. Perhaps its a reserved word?

Comment by Alexander Vladishev [ 2011 Dec 23 ]

The application name shouldn't affect on server operation in any way. The server side does not process applications! Similar it is simple coincidence.

Try once again.

Comment by richlv [ 2011 Dec 23 ]

that indeed seems quite unlikely. you could try snmpget for the same oids from the zabbix server when it starts to fail. if you can reliably reproduce this situation, please, reopen this issue - but make sure to reproduce exact steps a few times because it would be highly unusual to be true

Comment by Marc Herren [ 2011 Dec 23 ]

I could easily recreate it several times.

First I tough it might be related to ZBX-4277 but using DNS did not solve the issue.

By coincidence I figured out that I lost all my host as soon as I used "Interfaces" as application name.

To sum it up:

  • I reproduced this error on at least 5 different hosts
  • Those host where running fine with snmp for over 24h
  • I only added the application name to the "Interfaces" and then after 2-3 minutes the hosts was gone.

I'll be back at work on the 3 of january and if you want I can perform any debug task you want.

Comment by Marc Herren [ 2011 Dec 23 ]

and yes, the host is responding at that moment by snmpget/walk on all the OID's I am monitoring.

Comment by dimir [ 2012 Apr 17 ]

Confirmed. With this exact Zabbix version assigning an SNMP item to any Application (any name will affect, not just "Interfaces") results in SNMP host unavailability.

Comment by dimir [ 2012 Apr 17 ]

Duplicates ZBX-4425.

Comment by dimir [ 2012 Apr 17 ]

This was fixed in pre-1.9.9 r24033.

Comment by dimir [ 2012 Apr 17 ]

Reopening to add more details. The problem was that on item update frontend was setting item interface to NULL without a reason.

Comment by dimir [ 2012 Apr 17 ]

Remove assignee.

Comment by dimir [ 2012 Apr 17 ]

Reopening to fix Resolution.

Comment by dimir [ 2012 Apr 17 ]

Finally properly closed.

Generated at Sun Apr 06 00:11:23 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.