In some cases, the logrotate is not fast enough rotating the
logfile after sighub has been send to inputfilegen process. It appears
to happen more often on github CI machines, when it happens,
inputfilegen reopens the NOT yet rotated file and keeps writing
into it. However most messages written until the next sighub are lost
after the logfile finally is rotated.
In order to avoid this, I have added an extra sleep between file
CLOSE and OPEN after sighub with a default of 5ms which appears to work
very well. This should give logrotate enough time to perform the
actuzal rotate.
Also added another parameter to inputfilegen to keep the process
open after finish. Which helps syncing with the testcases.
closes: https://github.com/rsyslog/rsyslog/issues/5000
When a to-be-monitored file is being rotated, some messages may be lost or
duplicated. In case of duplication, many file lines may be duplicated
depending on actual timing. The whole bug was primarily timing depenedent
in general. It most often was visible in practice when the monitored
file was very frequently rotated (we had some report with every few
seconds).
Note that while we try hard to not lose any messages, input file
rotation always has some loss potential. This is inevitable if
the monitored file is being truncated.
Also note that this bugfix affects imfile, only. It has nothing to do
and no relation to rsyslog output files being rotated on HUP.
closes: https://github.com/rsyslog/rsyslog/issues/4797
