I used this patch and already works for me
From 0bd4044fa557da490495fc80659ddc8ed0fcc57e Mon Sep 17 00:00:00 2001
From: Bart Van Assche <[email protected]>
Date: Sat, 15 Oct 2011 14:45:08 +0200
Subject: [PATCH] CHANGES: snmplib: Change default number of retries back from 0 to 5

This patch fixes a bug introduced via commit 6cac050 (May 5, 2011,
added support for specifying the default number of retries in
snmpd.conf).

---
 snmplib/snmp_api.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Index: net-snmp-5.7.1/snmplib/snmp_api.c
===================================================================
--- net-snmp-5.7.1.orig/snmplib/snmp_api.c
+++ net-snmp-5.7.1/snmplib/snmp_api.c
@@ -704,6 +704,8 @@ _init_snmp(void)
 
     netsnmp_ds_set_int(NETSNMP_DS_LIBRARY_ID, 
                        NETSNMP_DS_LIB_HEX_OUTPUT_LENGTH, 16);
+    netsnmp_ds_set_int(NETSNMP_DS_LIBRARY_ID, NETSNMP_DS_LIB_RETRIES,
+                       DEFAULT_RETRIES);
 
 #ifdef NETSNMP_USE_REVERSE_ASNENCODING
     netsnmp_ds_set_boolean(NETSNMP_DS_LIBRARY_ID, 
@@ -1180,12 +1182,8 @@ _sess_copy(netsnmp_session * in_session)
     }
 
     if (session->retries == SNMP_DEFAULT_RETRIES) {
-        int retry = netsnmp_ds_get_int(NETSNMP_DS_LIBRARY_ID,
-                                       NETSNMP_DS_LIB_RETRIES);
-        if (retry < 0)
-            session->retries = DEFAULT_RETRIES;
-        else
-            session->retries = retry;
+        session->retries = netsnmp_ds_get_int(NETSNMP_DS_LIBRARY_ID,
+                                              NETSNMP_DS_LIB_RETRIES);
     }
     if (session->timeout == SNMP_DEFAULT_TIMEOUT) {
         int timeout = netsnmp_ds_get_int(NETSNMP_DS_LIBRARY_ID,

Take a look https://support.zabbix.com/browse/ZBX-4393#comment-77173

also see ZBXNEXT-1668 for additional info on how 2.2 changed this

As we have interfaces in zabbix already, it would be probably the most reasonable to introduce such feature on interface level, similarly to ZBXNEXT-2301.

Per item is not required at all and would be complicated to manage.

When introducing it take into account ZBX-8538.

Let's extend current feature request to include individual timeout handling.
For me it looks absolutely reasonable to implement both things (timeout for every interface, retry - for snmp only) in one development.
Configurable timeout for every interface would be probably even more valuable feature than snmp retries.

Issue summary has been updated.

It would resolve other issues like:
ZBX-7862 - for IPMI
ZBXNEXT-2252 - for SSH
ZBXNEXT-2721 - a bit different thing, but still - for network discovery

Oleksiy, can not add a timeout for the interface? And add a timeout for items?

Artur, hmm, I'm sorry, but cannot understand what is the question?
Do you want to say that Timeout per item would be better than per host interface ?

Sorry for my bad English.

Yes, I meant it. Timeout for per item will be better.
You can run external scripts with timeout=30s and SNMP with timeout=1s on one host.

It will be of course (re)considered before development what would be better - item or interface.

I still believe that interface will be better.
It will be more easy to manage, confroll etc. Remember that you can always create several interfaces (with identical IP:PORT) and then select desired interface in items configuration (although it's not so easy to distinguish every interface). As I see currently interfaces with identical type are sorted by ID in host configuration form and in item configuration form too.

We could for example extend the drop-down interfaces list including bulk, timeout, retries parameters to every list line.
For example 192.168.0.1:161:B:10:2 - would mean bulk enabled, 10 secs timeout and 2 retries.
or 192.168.0.1:10050::5: - agent interface with 5 secs timeout.

But main question is: will it be developed at all and when ? <- that's the most important thing

Which interface will work with LLD?
For example I have a external script on LLD, how can I increase the timeout on the LLD, but not increase it on an item if i have two snmp interface?
192.168.0.1:161:B:1:2-for snmp items
192.168.0.1:161:B:10:1-for lld

"External check" items also have interface field.
Discovery rule and prototypes can use different interfaces.

What is not very good that "Database monitor" items do not have interfaces ...

But using interfaces can have similar troubles as discussed in ZBXNEXT-735

If you do the time out settings on the interface AND the items this would be ideal. This way the possibility is that at the host level the default snmp timeout may be X and if required at the item level the snmp time out may be XX. This could be used in the example when the snmp daemon is actually executing a external script on the remote host (using exec or extend) to get the data and may take longer than the normal sysuptime etc... If it is implemented at the host and item level then this will cater for most requirements for all items types.

As this is oldest ZBXNEXT, I'm posting here.
It's just an attempt to mention all possible issues where requested to add some feature to interface or move it from item level:
ZBXNEXT-2613 - SNMP version should be set at interface level, not item level
ZBXNEXT-1274 - Configurable JMX Endpoint
ZBXNEXT-1977 - Allow JMX Host interfaces to have a username and password. Let jmx items inherit it.

This looks like umbrella ticket for for all per item (type) timeout requests, so I'll leave my thoughts here. ODBC checks should not be forgotten. Currently there is only timeout for connection phase, query itself and all underlying network communication can last indefinitely long.

I re-open this ZBXNEXT because could be usefull to have a different Timeout for some specific Item Check (big rest-api or complex pre-proc steps).
I know, it's better to stay very close to zero but the real life sometimes is different
Thanks so much

One type of 'timeout' I think could to be looked at here:

• Item configurable value for 'poller timeout' per item and it would override the Zabbix Server/Proxy setting (Timeout=XXX) for the specific item.

This would mean that when you have some items that may take longer than the existing maximum (30 seconds) say for example a discovery/external script/odbc query that is slow (API, Complex Database Query etc...) you could configure the 'poller timeout' just for this item say for example '60s'.

Not going into the implementation of this in detail, but you would look at putting in item validation perhaps to enforce poller timeout should be less than item interval etc...

We are implementing centralised management of item timeouts in 7.0 under this ticket. It will enable a global timeout (as it is now) and ability to override it on proxy (also managed from UI or API) and then on item level. All timeouts used for data collection will be managed from UI!

Implemented in:

• 7.0.0alpha5 (master) df3757fcef0, f22d7cd7c75

Documentation (7.0) updated:

• Introduction > What's new in Zabbix 7.0.0
• Installation > Upgrade notes for 7.0.0
• Quickstart > New item

• Configuration > Items > Creating an item
• Configuration > Items > Mass update
• Configuration > Items > Item types:
  • Zabbix agent 
  • SNMP agent
  • Simple checks
  • Internal checks
  • SSH checks
  • ODBC monitoring
  • HTTP agent
  • Script items

• Configuration export/import
• Configuration export/import > Templates
• Configuration export/import > Hosts

• Discovery > Low-level discovery
• Discovery > Low-level discovery > Item prototypes

• Distributed monitoring > Proxies
• Web interface > Frontend section > Administration > General

• Appendixes > Process configuration > Zabbix server
• Appendixes > Process configuration > Zabbix proxy
• Appendixes > Process configuration > Zabbix agent 2 plugins > Modbus plugin
• Appendixes > Process configuration > Zabbix agent 2 plugins > MQTT plugin
• Appendixes > Protocols > Zabbix agent 2 protocol
• Appendixes > Protocols > Header
• Appendixes > Items > Passive and active agent checks
• Appendixes > Macros > User macros supported by location