i586, logfetch: ... delta NNN bytes exceeds max buffer size 0
list Sergey
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
list Japheth Cleaver
▸
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
list Sergey
▸
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
list 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
list Sergey
▸
On Tuesday 24 May 2016, you 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.
Things got even more interesting. I added fourth format and it contans
real MAXCHECK (I increased it to 2048000) value:
- errprintf("logfetch: %s delta %zu bytes exceeds max buffer size %zu; skipping some data\n", filename, bufsz, MAXCHECK);
+ errprintf("logfetch: %s delta %zu bytes exceeds max buffer size %zu,%zu; skipping some data\n", filename, bufsz, MAXCHECK);
A log string now:
2016-07-04 17:26:21.345027 logfetch: /var/log/mail/all delta 9443833 bytes exceeds max buffer size 0,2048000; skipping some
data
--
Regards, Sergey
list Sergey
▸
On Tuesday 24 May 2016, you 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.
I found. Format %zu should be used for size_t, but bufsz defined as off_t:
#ifdef _LARGEFILE_SOURCE
off_t bufsz;
#else
long bufsz;
#endif
%zu should be changed to %llu or size_t should be used for bufsz.
--
Regards, Sergey