Uploaded image for project: 'ZABBIX BUGS AND ISSUES'
  1. ZABBIX BUGS AND ISSUES
  2. ZBX-2695

Actions are sometimes not executed. The problem with caching 'nextid'.

XMLWordPrintable

    • Icon: Incident report Incident report
    • Resolution: Fixed
    • Icon: Blocker Blocker
    • 1.8.3
    • 1.8.3
    • Server (S)
    • None
    • FreeBSD 8.0-RELEASE-p2
      mysql-server-5.5.4
      Zabbix last trunk

      I found this bug thanks to the topic on the forum: http://www.zabbix.com/forum/showthread.php?t=17634
      The problem arose because of - ZBXNEXT-338 added caching of eventid's

      My configuration:

      trigger:

      {MyHostName:eventlog[Test].logseverity(0)}

      =4
      action very simle with one condition: Host = "MyHostName"

      My situation: Before the server start up the table 'events' contain one row with eventid = 300000 and in the table 'ids' row 'events' contain nextid = 300000
      At the stage of starting the server changes the field 'nextid' to 300256 in table 'ids'. I understand that this is so you intended - caching.

      After this GUI uses a table 'ids' to get the next free 'eventid' for table 'events', and the server uses the cache in memory. In the here and there is a problem.

      As a result, for example, if a user in the GUI editing trigger multiple times (Diasable and Enable, or modify the expression), then this leads to a unpredictable effect because in the table 'events' events from the GUI will always be written with a more senior 'eventid', compared with those events which write server.

      This is a false server behavior such as checking in Action 'events.c', on the condition * (3) UNKNOWN/UNKNOWN/FALSE

      How to reproduce the problem - see the picture. There-designed all the necessary observations.
      To the problem itself has disappeared, you need the server write to the table 'events' more than 256 (# define ZBX_RESERVE 256) of any event and then the next trigger calculation make write of event with a more big ID and solve the problem with the condition (3) UNKNOWN/UNKNOWN/FALSE "
      This problem may not be very inconspicuous on systems where a large flow of events is generated, but little can be quite noticeable.

      I see the following two solutions:
      1. We must change and improve caching.
      2. Edit 'events.c'
      as a function of "get_latest_event_status" change the sort order. Now a field that represents the true sequence of events was a field 'clock':

      "Order by object desc, objectid desc, eventid desc",
      substituted:
      "Order by object desc, objectid desc, clock desc, eventid desc",

      I tested the second solutions and it helped - OK messages always come.

      I have a debug log file server with the problem of the picture if need be I will send.

            Unassigned Unassigned
            zalex_ua Oleksii Zagorskyi
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: