New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(imfile) File truncation detect by comparing current offset and file size on disk #514
Conversation
Looks like the change introduced a regression in tests. I will try to get a Ubuntu environment and verify locally. If anyone knows what failed exactly please let me know, thanks. |
According to the travis build log, failed test was What I did was starting a clean 12.04 container, install the dependencies (+ libgnutls-dev) and executed build steps as defined in Then I tried to execute the So this could be a intermittent problem in the test code, @rgerhards is it possible to re-trigger the travis CI build for this PR?
|
Another proof: I saw the build https://travis-ci.org/rsyslog/rsyslog/builds/79089258 for PR #513 was successful, only difference was just one comment change inside |
I verified, you were indeed hit by a glitch in the testbench. But may I kindly request to make this feature optional and turned off by default. We had such a bad time with this logic that I want to make sure it must be explicitely be opted in. Thanks! |
@rgerhards That's totally acceptable! Do you want me to update this with a C macro or you will do it yourself? I myself will do long duration test soon and will let you know if I run into trouble. Thanks! |
It would be great if you could amend your commit. I can do it, but I am pretty busy, so I could probably work on it around december this year. If you look at it, be aware that there are two types of config statements: legacy ones (the one starting with a dollar sign) and the current system. We do not add any legacy ones anymore (legacy is not good for complex cases). To add statements, search for "pblk" and you'll see how to others are handled. Please also don't forget to update the doc at https://github.com/rsyslog/rsyslog-doc |
It will be a challenge for me to make it right, let me verify my patch in real prod environment for a couple of days first. I will try to get back on this soon. Thanks again! |
Hi @rgerhards, I took some time on the related code today, here's what I am thinking:
My understanding is that this requires to upgrade |
Hi @rgerhards, I tested the current patch in real environment and found it indeed introduces new problem: when input load is heavy it sometimes send many duplicate message to output, even when there's no truncation happened. I am closing this pull request, but I still think issue #511 is a big deal and should be fixed. FYI my test was to use imfile and also output to a file, input > 1024 records per second, each record is 512 bytes long. |
Attempt to fix rsyslog#511. This is an enhanced version based on rsyslog#514, works fine for us so far. As discussed before, I added an opt-in flag 'reopenOnTruncate' and default is "off".
Attempt to fix rsyslog#511. This is an enhanced version based on rsyslog#514, works fine for us so far. As discussed before, I added an opt-in flag 'reopenOnTruncate' and default is "off".
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
My attempt to fix #511. Suggest to review commits one by one.
Tested manually and also with following command sequence.
cp
will truncate the target file asopen("/tmp/input.log", O_WRONLY|O_TRUNC) = 4
.