-
Type:
Problem report
-
Resolution: Unresolved
-
Priority:
Trivial
-
None
-
Affects Version/s: 7.0.30
-
Component/s: Server (S)
-
Environment:Summary
Zabbix 7.0.30 intermittently stops dispatching all six direct SNMPv3 items for an individual CertaUPS/Phoenixtec UPS host.
The affected host varies between occurrences. The issue has so far been observed on multiple hosts linked to the same CertaUPS SNMPv3 template, including C1-UPS, C3-UPS, A3-UPS and A4-UPS.
There are 33 hosts linked to this template.
The issue is now occurring approximately daily.
Expected result
Each of the six SNMP items should be collected at its configured 1-minute interval.
Selecting Execute now should dispatch the selected item to an SNMP poller and write a new history value.
Actual result
All six SNMP items on an individual affected host stop updating at exactly the same time.
The items appear in Administration -> Queue -> Queue details and continue becoming increasingly delayed.
During the failure:
* Items remain enabled.
* Item runtime state remains supported.
* The SNMP interface remains available.
* The interface has no error and no disable_until back-off.
* ICMP to the affected UPS succeeds.
* Direct SNMPv3 requests from the Zabbix server succeed immediately.
* Other SNMP hosts continue polling.
* No timeout, authentication or communication error is logged for the affected UPS.
Execute now behaviour:
* Execute now creates a task with type=6.
* The task reaches status=3.
* The affected item ID does not appear in SNMP poller debug logging.
* No new history value is written.
Restarting only zabbix-server immediately restores all six items.
Example occurrence
Date: 23 September 2026
Affected hosts:
A3-UPS
IP: 192.168.xxx.xxx
Battery Charge item ID: 120878
A4-UPS
IP: 192.168.xxx.xxx
Battery Charge item ID: 120948
A3-UPS stopped writing numeric history at:
2026-09-23 06:09:12 UTC
A4-UPS stopped writing numeric history at:
2026-09-23 06:29:13 UTC
Direct SNMPv3 queries to both cards returned successfully while Zabbix history remained frozen.
Five Execute now tasks were created for item IDs 120878 and 120948. All had type=6 and status=3, but neither target item appeared in SNMP poller debug logging and neither history timestamp changed.
After restarting zabbix-server at 07:42:55 UTC:
A3-UPS updated all six items at 07:43:12 UTC.
A4-UPS updated all six items at 07:43:13 UTC.
Template details
The attached CertaUPS SNMPv3 template contains six direct SNMP agent items using standard UPS-MIB OIDs:
Battery Charge:
1.3.6.1.2.1.33.1.2.4.0
Runtime Remaining:
1.3.6.1.2.1.33.1.2.3.0
Input Voltage:
1.3.6.1.2.1.33.1.3.3.1.3.1
Output Voltage:
1.3.6.1.2.1.33.1.4.4.1.2.1
UPS Load:
1.3.6.1.2.1.33.1.4.4.1.5.1
UPS Status:
1.3.6.1.2.1.33.1.1.2.0
The items have no preprocessing, discovery or dependent-item configuration.
Tests already performed
* Increased StartSNMPPollers from 10 to 20. The issue still recurs.
* Direct ping and SNMPv3 queries succeed during the failure.
* Execute now tasks are created and marked completed but do not result in SNMP poller execution or history.
* snmp_cache_reload has previously been tested and does not recover this UPS issue.
* Disabling combined SNMP requests has previously been tested and does not prevent the issue.
* Restarting zabbix-server consistently recovers the affected items immediately.
Frequency
The symptom can affect any host linked to the CertaUPS SNMPv3 template rather than a single recurring host.
The failure has been observed on at least:
C1-UPS
C3-UPS
A3-UPS
A4-UPS
Additional observations
The Zabbix server continues processing unrelated SNMP items while the affected UPS items remain queued.
The affected items are scheduled through the Zabbix server directly and are not monitored through a proxy.
Summary Zabbix 7.0.30 intermittently stops dispatching all six direct SNMPv3 items for an individual CertaUPS/Phoenixtec UPS host. The affected host varies between occurrences. The issue has so far been observed on multiple hosts linked to the same CertaUPS SNMPv3 template, including C1-UPS, C3-UPS, A3-UPS and A4-UPS. There are 33 hosts linked to this template. The issue is now occurring approximately daily. Expected result Each of the six SNMP items should be collected at its configured 1-minute interval. Selecting Execute now should dispatch the selected item to an SNMP poller and write a new history value. Actual result All six SNMP items on an individual affected host stop updating at exactly the same time. The items appear in Administration -> Queue -> Queue details and continue becoming increasingly delayed. During the failure: * Items remain enabled. * Item runtime state remains supported. * The SNMP interface remains available. * The interface has no error and no disable_until back-off. * ICMP to the affected UPS succeeds. * Direct SNMPv3 requests from the Zabbix server succeed immediately. * Other SNMP hosts continue polling. * No timeout, authentication or communication error is logged for the affected UPS. Execute now behaviour: * Execute now creates a task with type=6. * The task reaches status=3. * The affected item ID does not appear in SNMP poller debug logging. * No new history value is written. Restarting only zabbix-server immediately restores all six items. Example occurrence Date: 23 September 2026 Affected hosts: A3-UPS IP: 192.168.xxx.xxx Battery Charge item ID: 120878 A4-UPS IP: 192.168.xxx.xxx Battery Charge item ID: 120948 A3-UPS stopped writing numeric history at: 2026-09-23 06:09:12 UTC A4-UPS stopped writing numeric history at: 2026-09-23 06:29:13 UTC Direct SNMPv3 queries to both cards returned successfully while Zabbix history remained frozen. Five Execute now tasks were created for item IDs 120878 and 120948. All had type=6 and status=3, but neither target item appeared in SNMP poller debug logging and neither history timestamp changed. After restarting zabbix-server at 07:42:55 UTC: A3-UPS updated all six items at 07:43:12 UTC. A4-UPS updated all six items at 07:43:13 UTC. Template details The attached CertaUPS SNMPv3 template contains six direct SNMP agent items using standard UPS-MIB OIDs: Battery Charge: 1.3.6.1.2.1.33.1.2.4.0 Runtime Remaining: 1.3.6.1.2.1.33.1.2.3.0 Input Voltage: 1.3.6.1.2.1.33.1.3.3.1.3.1 Output Voltage: 1.3.6.1.2.1.33.1.4.4.1.2.1 UPS Load: 1.3.6.1.2.1.33.1.4.4.1.5.1 UPS Status: 1.3.6.1.2.1.33.1.1.2.0 The items have no preprocessing, discovery or dependent-item configuration. Tests already performed * Increased StartSNMPPollers from 10 to 20. The issue still recurs. * Direct ping and SNMPv3 queries succeed during the failure. * Execute now tasks are created and marked completed but do not result in SNMP poller execution or history. * snmp_cache_reload has previously been tested and does not recover this UPS issue. * Disabling combined SNMP requests has previously been tested and does not prevent the issue. * Restarting zabbix-server consistently recovers the affected items immediately. Frequency The symptom can affect any host linked to the CertaUPS SNMPv3 template rather than a single recurring host. The failure has been observed on at least: C1-UPS C3-UPS A3-UPS A4-UPS Additional observations The Zabbix server continues processing unrelated SNMP items while the affected UPS items remain queued. The affected items are scheduled through the Zabbix server directly and are not monitored through a proxy.
Zabbix 7.0.30 intermittently stops scheduling all direct SNMP
items for individual SNMPv3 UPS Monitoring card hosts.
The issue can affect any host linked to my custom CertaUPS SNMPv3
template (yaml attached).
Items remain enabled and supported. Interfaces remain available.
Direct SNMPv3 requests succeed.
Execute now creates type 6 tasks which become status 3
(completed), but affected item IDs do not reach SNMP poller
debug logging and no history is written.
Other SNMP hosts continue polling normally.
Restarting zabbix-server immediately restores all affected items.