i586, logfetch: ... delta NNN bytes exceeds max buffer size 0
Hello.
I saw a strange problem since 4.3.26 (I not used versions between 4.3.16 and 4.3.26). 4.3.27 contains it too.
2016-05-23 14:44:14.052315 logfetch: /var/log/httpd2/error_log delta 2098854 bytes exceeds max buffer size 0; skipping some data 2016-05-23 14:45:54.580396 logfetch: /var/log/httpd2/error_log delta 2105418 bytes exceeds max buffer size 0; skipping some data 2016-05-23 14:47:35.120075 logfetch: /var/log/httpd2/error_log delta 2109847 bytes exceeds max buffer size 0; skipping some data
max buffer size 0 somehow. I built i586 and x86_64 binary from one srpm. x86_64 works fine. Spec file is not contains architecture dependent parts. I see that this is macro in the client/logfetch.c (#define MAXCHECK 102400) and I don't understand how this is possible.
Can anyone confirm the problem on i586 ? Log continues to be analysed however.
-- Regards, Sergey
On Mon, May 23, 2016 5:59 am, Sergey wrote:
Hello.
I saw a strange problem since 4.3.26 (I not used versions between 4.3.16 and 4.3.26). 4.3.27 contains it too.
2016-05-23 14:44:14.052315 logfetch: /var/log/httpd2/error_log delta 2098854 bytes exceeds max buffer size 0; skipping some data 2016-05-23 14:45:54.580396 logfetch: /var/log/httpd2/error_log delta 2105418 bytes exceeds max buffer size 0; skipping some data 2016-05-23 14:47:35.120075 logfetch: /var/log/httpd2/error_log delta 2109847 bytes exceeds max buffer size 0; skipping some data
max buffer size 0 somehow. I built i586 and x86_64 binary from one srpm. x86_64 works fine. Spec file is not contains architecture dependent parts. I see that this is macro in the client/logfetch.c (#define MAXCHECK 102400) and I don't understand how this is possible.
Can anyone confirm the problem on i586 ? Log continues to be analysed however.
Sergey,
This is the first report I've received, but the values indicated are suspiciously right over (2M = 2097152), which makes me think a 32bit issue is very possible. ftell() would be being used there unless _LARGEFILE_SOURCE is specified, and it's only returning a long back for the file position.
This definitely seems like a bug.
What compiler and distro are you using?
Regards, -jc
On Tuesday 24 May 2016, J.C. Cleaver wrote:
This is the first report I've received, but the values indicated are suspiciously right over (2M = 2097152), which makes me think a 32bit issue is very possible.
But MAXCHECK is a macro definition. The algorithm may be wrong but MAXCHECK is written to the log as zero.
What compiler and distro are you using?
Distro ALT Linux. I built it for p7 (gcc 4.7.2) and p8 (gcc 5.3.1) branches.
-- Regards, Sergey
On Tuesday 24 May 2016, J.C. Cleaver wrote:
which makes me think a 32bit issue is very possible. ftell() would be being used there unless _LARGEFILE_SOURCE is specified,
Xymon built with -D_LARGEFILE_SOURCE on i586.
4.3.26 build log for ALT Linux p7/t7 branches: http://git.altlinux.org/tasks/archive/done/_156/160096/build/100/i586/log (with standard MAXCHECK)
4.3.27 build log for ALT Linux p7/t7 branches: http://git.altlinux.org/tasks/archive/done/_159/163649/build/100/i586/log (with increased MAXCHECK)
-- Regards, Sergey
participants (2)
-
a_s_y＠sama.ru
-
cleaver＠terabithia.org