Bug : Zabbix-1.1beta6 - item "Update interval"

[SAT QPass]

This is not really a bug, but an issue, and not serious as that, I apologize for the "bug" misnomer. I have provided a patch to the items.php file which addresses this....

The php code on the frontend allows for a value of 99999 (or slightly more than 1 day). I had used it at one point (previous beta) and subsequently deleted. I have since dropped my tables and recreated them from scratch from the zabbix schema file.

I had opted to bring such a data point today in 1.1beta6 (schema creation was 1.1beta5) and found that it no longer accepts a value of 99999.

Code from the frontend which suggests it is possible....

Update&nbsp;interval&nbsp;(in&nbsp;sec)</td>
<td class="form_row_r">
<input class="biginput" name="delay" size="5" value="99999"/>

What the database schema reports.... (this is from 1.1beta6 which is still wrong)...

CREATE TABLE items (
        itemid          int(4) NOT NULL auto_increment,
        type            int(4) DEFAULT '0' NOT NULL,
        snmp_community  varchar(64) DEFAULT '' NOT NULL,
        snmp_oid        varchar(255) DEFAULT '' NOT NULL,
        snmp_port       int(4) DEFAULT '161' NOT NULL,
        hostid          int(4) NOT NULL,
        description     varchar(255) DEFAULT '' NOT NULL,
        key_            varchar(64) DEFAULT '' NOT NULL,
[COLOR=Red]        delay           int(4) DEFAULT '0' NOT NULL,[/COLOR]
        history         int(4) DEFAULT '90' NOT NULL,
        trends          int(4) DEFAULT '365' NOT NULL,
-- lastdelete is not longer required
--      lastdelete      int(4) DEFAULT '0' NOT NULL,
        nextcheck       int(4) DEFAULT '0' NOT NULL,
        lastvalue       varchar(255) DEFAULT NULL,
        lastclock       int(4) DEFAULT NULL,
        prevvalue       varchar(255) DEFAULT NULL,
        status          int(4) DEFAULT '0' NOT NULL,
        value_type      int(4) DEFAULT '0' NOT NULL,
        trapper_hosts   varchar(255) DEFAULT '' NOT NULL,
        units           varchar(10)     DEFAULT '' NOT NULL,
        multiplier      int(4)  DEFAULT '0' NOT NULL,
        delta           int(1)  DEFAULT '0' NOT NULL,
        prevorgvalue    double(16,4)  DEFAULT NULL,
        snmpv3_securityname     varchar(64) DEFAULT '' NOT NULL,
        snmpv3_securitylevel    int(1) DEFAULT '0' NOT NULL,
        snmpv3_authpassphrase   varchar(64) DEFAULT '' NOT NULL,
        snmpv3_privpassphrase   varchar(64) DEFAULT '' NOT NULL,

        formula         varchar(255) DEFAULT '0' NOT NULL,
        error           varchar(128) DEFAULT '' NOT NULL,

        lastlogsize     int(4) DEFAULT '0' NOT NULL,
        logtimefmt      varchar(64) DEFAULT '' NOT NULL,

        PRIMARY KEY     (itemid),
        UNIQUE          shortname (hostid,key_),
--      KEY             (hostid),
        KEY             (nextcheck),
        KEY             (status)
) type=InnoDB;

[Alexei]

The de;ay is currently limited to 65535 seconds, items.php

"delay"=> array(T_ZBX_INT, O_OPT, NULL, BETWEEN(0,65535),'isset({save})&&{type}!=2'),

As for the upgrade patch, it shoudn't contain the '-'. It is a known issue which is already fixed.

[SAT QPass]

The de;ay is currently limited to 65535 seconds, items.php

"delay"=> array(T_ZBX_INT, O_OPT, NULL, BETWEEN(0,65535),'isset({save})&&{type}!=2'),

As for the upgrade patch, it shoudn't contain the '-'. It is a known issue which is already fixed.

May I ask what the reason for this limit is? 18.2 hours seems particularly arbitrary. Is there a reason this could not be increased to a full 24 hours?

[Alexei]

Sure, it can be increased!

[SAT QPass]

Sure, it can be increased!

I have attached the patch to items.php.

--- items.php   2006-02-07 05:04:32.000000000 -0800
+++ items_delay_86400.php       2006-02-14 14:32:50.000000000 -0800
@@ -52,7 +52,7 @@
                "description"=> array(T_ZBX_STR, O_OPT,  NULL,  NOT_EMPTY,'isset({save})'),
                "key"=>         array(T_ZBX_STR, O_OPT,  NULL,  NOT_EMPTY,'isset({save})'),
                "host"=>        array(T_ZBX_STR, O_OPT,  NULL,  NOT_EMPTY,'isset({save})'),
-               "delay"=>       array(T_ZBX_INT, O_OPT,  NULL,  BETWEEN(0,65535),'isset({save})&&{type}!=2'),
+               "delay"=>       array(T_ZBX_INT, O_OPT,  NULL,  BETWEEN(0,86400),'isset({save})&&{type}!=2'),
                "history"=>     array(T_ZBX_INT, O_OPT,  NULL,  BETWEEN(0,65535),'isset({save})'),
                "status"=>      array(T_ZBX_INT, O_OPT,  NULL,  BETWEEN(0,65535),'isset({save})'),
                "type"=>        array(T_ZBX_INT, O_OPT,  NULL,  IN("0,1,2,3,4,5,6,7"),'isset({save})'),

[elkor]

May I ask what the reason for this limit is? 18.2 hours seems particularly arbitrary. Is there a reason this could not be increased to a full 24 hours?

somebody failed to whip out their hex calculator ;-)

[SAT QPass]

somebody failed to whip out their hex calculator ;-)

I am suitably shamed. However, I still needed 24 hours

[bbrendon]

Is > 65535 going to be allowed in beta8? I have some 86400's ...and i just ran into this while editing some of my items. According to the thread, the datatype is plenty. If you want to limit us to 65535 then use unsigned int(2)

I'm on beta7.