[ZBX-5027] Once monitoring a log file more than 2GB, the log will be never monitored. Created: 2012 May 21  Updated: 2017 May 30  Resolved: 2012 May 22

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G), Proxy (P), Server (S)
Affects Version/s: 1.8.13
Fix Version/s: 1.8.14rc1

Type: Incident report Priority: Major
Reporter: Takanori Suzuki Assignee: dimir
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Agent: Linux x86_64
Server: Linux x86_64
But perhaps other environments are also affected.

Issue Links:
Duplicate

 Description   

Almost same issue with ZBXNEXT-1220.
I know 1.8.x will not change the DB schema and 1.8.x dosen't support over 2GB log file.
So, I don't expect Zabbix to be fixed to become monitor over 2GB log file.

However I think following behavior is a problem.
"If once Agent monitor a log file more than 2GB and then Agent restarted, the log will be never monitored"
Because if 64bit agent send "lastlogsize" over 32bit value, atoi() in server will overflow and receive the value as negative value.

------------------------------------------------------------ branches/1.8 (r27653)-------------------------------------------------------
src/zabbix_server/trapper/trapper.c:369: av.lastlogsize = atoi(lastlogsize);
----------------------------------------------------------------------------------------------------------------------------------------------------

Then if agent restart, agent will monitor the log file from negative value "lastlogsize".
Because "lastlogsize" is negative, the lseek will never succeed and the "lastlogsize" will never become positive value.

------------------------------------------------------------ branches/1.8 (r27653)-------------------------------------------------------
src/zabbix_agent/logfiles.c:501: if ((off_t)-1 != lseek(fd, (off_t)*lastlogsize, SEEK_SET))
src/zabbix_agent/logfiles.c:628: if ((off_t)-1 != lseek(f, (off_t)*lastlogsize, SEEK_SET))
----------------------------------------------------------------------------------------------------------------------------------------------------

I suggest Zabbix 1.8.x to return NOTSUPPORTED if the log file is over 2GB.
And if the log file become less 2GB, Zabbix will monitor again the log file.

BTW, I think ZBXNEXT-1220 is come from what I told Alexei at Japanese Zabbix meeting last week.
I told Alexei about this bug at there.

 Comments   
Comment by dimir [ 2012 May 22 ]

Could not reproduce it with:

Agent Linux x86_64
Server Linux x86_32

In that case DB gets INT_MAX (2147483647) stored as "lastlogsize" and if the log file shrinks after that the log monitoring continues from 0. I was using MySQL. Which DB were you using?

Comment by Takanori Suzuki [ 2012 May 22 ]

I also use MySQL.
The value turn to negative at following atoi().
------------------------------------------------------------ branches/1.8 (r27653)-------------------------------------------------------
src/zabbix_server/trapper/trapper.c:369: av.lastlogsize = atoi(lastlogsize);
----------------------------------------------------------------------------------------------------------------------------------------------------
Zabbix server get the negative value and store it to MySQL.
MySQL INT can store value from -2147483648 to 2147483647.
So, MySQL stores negative value.

Following code is easy to understand what occurs. (Please execute it in x86_64 environment.)
----------------------------------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int main()

{ int i; i = atoi("2147483647"); printf("%d\n",i); //if over 2147483647, atoi() returns negative value in x86_64 //Finally, the negative value will be stored in MySQL. i = atoi("2147483648"); printf("%d\n",i); i = atoi("3333333333"); printf("%d\n",i); }

----------------------------------------------------------------------------------------------

The output is following.

----------------------------------------------------------------------------------------------
2147483647
-2147483648
-961633963
----------------------------------------------------------------------------------------------

Comment by Takanori Suzuki [ 2012 May 22 ]

Your Zabbix Server should be x86_64 for reproduce the case.
Because atoi("2147483648") returns 2147483647 in x86_32, but atoi("2147483648") returns -2147483648 in x86_64.

To be strictly, if the string cannot be represented as integer, the behavior is undefined.
And gcc's atoi() works in different way in each architecture.

It looks work good in x86_32.
But even in x86_32, it's undefined behavior and it's not so good.

Comment by dimir [ 2012 May 22 ]

Exactly, just tested it.

By the way the place in the code is not really

src/zabbix_server/trapper/trapper.c:369

(this is to handle old XML protocol) but

$ sed -n '1476,1477p' src/libs/zbxdbhigh/proxy.c
if (SUCCEED == zbx_json_value_by_name(&jp_row, ZBX_PROTO_TAG_LOGLASTSIZE, tmp, sizeof(tmp)))
av->lastlogsize = atoi(tmp);

But this doesn't matter. The problem is indeed atoi(). We decided to fix agent. 1.8 agent will always fail and return ZBX_NOTSUPPORTED if log file size is over 2 GB.

Comment by Takanori Suzuki [ 2012 May 22 ]

> By the way the place in the code is not really
Oh, sorry my mistake.

> But this doesn't matter. The problem is indeed atoi(). We decided to fix agent. 1.8 agent will always fail and return ZBX_NOTSUPPORTED if log file size is over 2 GB.
I see. It looks good.
Thank you.

Comment by dimir [ 2012 May 22 ]

Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-5027.

Comment by Alexander Vladishev [ 2012 Jun 03 ]

Successfully tested!

Comment by dimir [ 2012 Jun 04 ]

Fixed in pre-1.8.14 r28029.

Comment by dimir [ 2012 Jun 04 ]

NOTE! In order to apply the fix please follow these steps:

1) recompile Zabbix agent
2) stop Zabbix agent
3) apply next SQL query to Zabbix database:

UPDATE items SET lastlogsize=0 WHERE lastlogsize<0;

4) start freshly compiled Zabbix agent

Generated at Sat Apr 20 15:24:40 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.