Repository navigation
When using CMD poller, Failure and Recovery dates may have incorrect values #5727
Description
Activity
- addedbugUndesired behaviourUndesired behaviourunverifiedSome days we don't have a clueSome days we don't have a clue
on Apr 14, 2024 Yea, he has a messed up sql_mode that does not allow for zero date.
@xmacan and I both have the dame sql mode
Spine insert all 0's just fine if you swith to cmd that device swaps to 1969Before swapping to cmd
MariaDB [cacti]> select hostname,description,status,status_fail_date,status_rec_date from host where description = 'mancinisw' \G
*************************** 1. row ***************************
hostname: 192.168.1.253
description: mancinisw
status: 1
status_fail_date: 2024-04-14 12:37:05
status_rec_date: 2024-04-14 12:30:02
1 row in set (0.001 sec)After
MariaDB [cacti]> select hostname,description,status,status_fail_date,status_rec_date from host where description = 'mancinisw' \G
*************************** 1. row ***************************
hostname: 192.168.1.253
description: mancinisw
status: 3
status_fail_date: 1969-12-31 19:32:49
status_rec_date: 1969-12-31 19:32:49
1 row in set (0.001 sec)Weird. It's more a thold issue IMHO.
- I don't have thold on this test bed I'm not in front of my pc so can't confirm 100%…On Sun, Apr 14, 2024, 13:29 TheWitness ***@***.***> wrote: Weird. It's more a thold issue IMHO. — Reply to this email directly, view it on GitHub <#5727 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADGEXTGMV3ZR6YF7LC3KX3DY5K4HZAVCNFSM6AAAAABGGIES42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJUGEZDQMZWG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>
I just fixed thold for this issue.
I've fixed this in the thold plugin.
I tested it without thold, it isn't thold issue.
SQL mode:
STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTIONThat is correct. But I corrected it in Thold.
- changed the title
[-][1.2.27][QA] - incorrect values status_fail_date and status_rec_date with cmd poller[/-][+]Incorrect values status_fail_date and status_rec_date with cmd poller[/+]on Apr 14, 2024 - addedconfirmedBug is confirm by dev teamBug is confirm by dev teamand removedunverifiedSome days we don't have a clueSome days we don't have a clue
on Apr 14, 2024 Okay fixing shortly. Great catch.
- added a commit that references this issue
on Apr 14, 2024 Yep this is good now
MariaDB [cacti]> select hostname,description,status,status_fail_date,status_rec_date from host where description = 'mancinisw' \G
*************************** 1. row ***************************
hostname: 192.168.1.253
description: mancinisw
status: 2
status_fail_date: 2024-04-14 19:19:05
status_rec_date: 2024-04-14 19:26:02
1 row in set (0.001 sec)- added a commit that references this issue
on Apr 15, 2024 If we only had it to begin with.
- changed the title
[-]Incorrect values status_fail_date and status_rec_date with cmd poller[/-][+]When using CMD poller, Failure and Recovery dates may have incorrect values[/+]on Apr 28, 2024 - locked and limited conversation to collaborators
on Jul 28, 2024 - addedstatus:confirmedNamespaced Cacti workflow labelNamespaced Cacti workflow labeltype:bugNamespaced Cacti workflow labelNamespaced Cacti workflow label
on Aug 30, 2026
If cmd poller is used, status_rec_date and staus_fail_date are around 1970-01-01 (@bmfmancini has 1969, I guess it is timezone/summer time).
New device, snmp works well, device is online:
+---------------------+---------------------+--------------------------------+--------+--------------------+------------------------+ | status_fail_date | status_rec_date | status_last_error | status | status_event_count | snmp_sysUpTimeInstance | +---------------------+---------------------+--------------------------------+--------+--------------------+------------------------+ | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | | 0 | 0 | 0 |I change snmp port to simulate down state:
| 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | Device did not respond to SNMP | 3 | 1 | 2271887200 |after few minutes:
| 1970-01-01 01:33:44 | 0000-00-00 00:00:00 | Device did not respond to SNMP | 1 | 1 | 2271887200 |after recovering:
| 1970-01-01 01:32:50 | 2024-04-14 18:50:00 | Device did not respond to SNMP | 3 | 0 | 2271923200 |after next poller cycle:
| 1970-01-01 01:32:50 | 1970-01-01 01:33:44 | Device did not respond to SNMP | 3 | 0 | 2271929200 |@bmfmancini confirmed it. With spine works fine