[ZBX-24172] scheduled intervals with "wd" are not working on Feb 29th (on leap year) Created: 2024 Mar 01  Updated: 2024 May 06  Resolved: 2024 May 06

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Server (S)
Affects Version/s: 5.0.42, 6.0.28, 6.4.13
Fix Version/s: 6.0.30rc1, 6.4.15rc1, 7.0.0rc1, 7.0 (plan)

Type: Problem report Priority: Critical
Reporter: Jan Tomiška Assignee: Sergejs Boidenko
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Linux RedHat servers, Postgres with Timescale DB, Apache web.

Attachments: PNG File reproduced.png    
Issue Links:
Causes
caused by ZBX-24174 Zabbix scheduler issues on 29. februa... Closed
Duplicate
is duplicated by ZBX-24185 Items with 'wd' prefix in the schedul... Closed
Team: Team A
Sprint: S24-W16/17, S24-W18/19
Story Points: 1

 Description   

Steps to reproduce:

  1. Create Scheduling Custom interval on item with for example "wd1-5h16m35"
  2. on 28.02. it works
  3. on 29.02. nothing is executed
  4. on 01.03. restart server to resolve (missing executions seems to run right after restart - not on the specified time)

Result:
Items arent collected on 29.02.

Expected:
Collected items.

Zabbix version is 5.0.4 here. But seen comment elsewhere that it appeared on 6.2.6 elsewhere.

 Comments   
Comment by Oleksii Zagorskyi [ 2024 Mar 13 ]

Confirmed, using recent v6.0.27

Steps to reproduce:
Use an item with scheduled interval "wd1-5s33"
I used agent item with key "agent.version". 

Set local time to cross a day soon to be sure the interval is working and start server:

# timedatectl set-time '2024-02-27 23:55:00'
# systemctl start zabbix-server

make sure data is collecting before and after day cross.
Fast forward to approach 29.2:

# timedatectl set-time '2024-02-28 23:53:00'

observe how the time change applied and data was collecting, but then suddenly stopped at Feb 29.
Restarting zabbix server at this point does not change things, data collection does not start.

But as soon as "wd1-5" part is removed and only "s33" is left (at ~18th minute), data collection is recovered itself (after automatic config cache reload).

So indeed the "wd" usage causing the issue.

History values for the item:

 

NOTE: later, when Feb 29th ends, on Mar 01, data collection recovers back.

Comment by Kim Jongkwon [ 2024 Apr 02 ]

The same problem has been confirmed with using versions 4.0.20 and 5.0.9
The issue might have started from the time scheduled intervals were introduced.

Comment by Sergejs Boidenko [ 2024 May 03 ]

Fixed in: 

Generated at Sat Apr 19 22:21:08 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.