Created attachment 410942 [details, diff] config.h inclusion order fix Ulogd includes config.h from include/ulogd/ulogd.h too late to use determined _FILE_OFFSET_BITS set to 64 on 32-bit x86 platform for all file api functions. This causes inability to write log files larger than 2 GiB in size. Attached patch resolves this problem.
Created attachment 410944 [details, diff] sorry, previous patch didn't actually fix the problem
(In reply to Tomasz Chilinski from comment #0) > Created attachment 410942 [details, diff] [details, diff] > config.h inclusion order fix > > Ulogd includes config.h from include/ulogd/ulogd.h too late to use > determined _FILE_OFFSET_BITS set to 64 on 32-bit x86 platform for all file > api functions. This causes inability to write log files larger than 2 GiB in > size. > Attached patch resolves this problem. You say the problem is that ulogd fails to write more than 2 GiB to a single logfile on 32-bit platforms. What happens then? Does it log any errors?
Simply it stops to write to log file altough process stays active. Doesn't log any problems.
Just to be sure did you check that on your system 'config.h' actually has _FILE_OFFSET_BITS set to 64?
Yes of course. Configure script properly detects required _FILE_OFFSET_BITS setting.
(In reply to Tomasz Chilinski from comment #5) > Yes of course. Configure script properly detects required _FILE_OFFSET_BITS > setting. Good, thanks for the info. I do not have a 32-bit system at hand, so it'll take me some time to set it up and try and reproduce your issue. In the meantime I can say that your patch in its current form cannot be added to the tree because if this is a reproducible problem with ulogd, then it should be fixed on the build system level. You've provided a way to fix it for a single output plugin only. Also it seems that somebody had a similar problem a long time ago (see [0]), but it looks like it was a problem with user configuration. 0: https://osdir.com/ml/netfilter/2009-03/msg00014.html
(In reply to Tomasz Chilinski from comment #5) > Yes of course. Configure script properly detects required _FILE_OFFSET_BITS > setting. Please attach your build.log and `emerge --info ulogd` output.
Created attachment 411424 [details, diff] build.log
Created attachment 411426 [details] emerge --info
Created attachment 411428 [details] build.log
Thank you.
Here you have it as attachments. > I can say that your patch in its current form cannot be added to the tree > because if this is a reproducible problem with ulogd, then it should be fixed > on the build system level. @Coacher: just take a look into output/ulogd_output_XML.c file from source tree. ../config.h is included before file function declarations in this file (fortunately). config.h is also included from include/ulogd/ulogd.h, but, unfortunately, config.h inclusion from ulogd.h for ulogd_output_LOGEMU.c is too late, because file function declarations has already been included from stdio.h while _FILE_OFFSET_BITS wasn't defined as 64. Here is snippet from output/ulogd_output_LOGEMU.c: #include <limits.h> #include <stdio.h> <------ file function declarations #include <stdlib.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <time.h> #include <ulogd/ulogd.h> <------- implicit config.h inclusion while defines _FILE_OFFSET_BITS as 64 #include <ulogd/conffile.h> How build system could modify inclusion order while these files are not touched at all by build system? This would be very invasive changes...
(In reply to Tomasz Chilinski from comment #12) > @Coacher: just take a look into output/ulogd_output_XML.c file from source > tree. > ../config.h is included before file function declarations in this file > (fortunately). > config.h is also included from include/ulogd/ulogd.h, but, unfortunately, > config.h inclusion from ulogd.h for ulogd_output_LOGEMU.c is too late, > because file function declarations has already been included from stdio.h > while _FILE_OFFSET_BITS wasn't defined as 64. > > Here is snippet from output/ulogd_output_LOGEMU.c: > #include <limits.h> > #include <stdio.h> <------ file function declarations > #include <stdlib.h> > #include <unistd.h> > #include <string.h> > #include <errno.h> > #include <time.h> > #include <ulogd/ulogd.h> <------- implicit config.h inclusion while defines > _FILE_OFFSET_BITS as 64 > #include <ulogd/conffile.h> > > How build system could modify inclusion order while these files are not > touched at all by build system? This would be very invasive changes... I can see the problem you are referring to. But what about other plugins? There are still lots of places where stdio.h is included prior to ulogd.h. Build system could add '-D_FILE_OFFSET_BITS=64' to CFLAGS at compile time if requested overriding the defaults. Not intrusive at all. I am just trying to figure out if there is a better way to fix it rather than to modify CFLAGS.
I see. You're right.
My attempt to fix include order was painful and not successful. Since we don't provide Gentoo users a way to disable large file support (anyone really wants it disabled nowadays?) it is safe to just append the needed flags.
Created attachment 411442 [details, diff] ulogd-large-file-support.patch Patch for the currently stable ulogd-2.0.4-r1 to fix large file support.
From now it can take some time to push this changes in tree and then stabilize the new ebuild if necessary. Hopefully ulogd-2.0.5 can be updated to fix this issue and then stabilized in one go. If you are desperate to have this fix on your system you will have to update the ebuild manually or use my overlay where this fix is already applied: https://github.com/Coacher/bonespirit.git
Thanks @Coacher!
Created attachment 411446 [details] ulogd-2.0.5-r1.ebuild ulogd-2.0.5-r1.ebuild with large file support fix
Created attachment 411448 [details, diff] 2.0.5..2.0.5-r1.patch
commit 39360fe201749544207e205bb418d1a0f6308ce1 Author: Manuel Rüger <mrueg@gentoo.org> Date: Thu Sep 10 00:55:13 2015 +0200 app-admin/ulogd: Proxy commit for Coacher. Fix support for large files. Gentoo-Bug: #559552 Package-Manager: portage-2.2.20.1
