El 30/11/16 a las 22:51, David Lang escribió:
On Wed, 30 Nov 2016, mosto...@gmail.com wrote:

According to documentation:

State files are used to track which parts of the monitored file are already processed.

  Do state files keep just "last reading position" or as doc suggests
  a file can be processed in multiple chunks(parts)?

I'd have to look at the format of the state file to be absolutly sure, but I think it just keeps track of the last reasing position. I don't think you can have multiple threads reading the same file, so if you read a file in chunks, each time you read a chunk it advances the position.
I asked 'cause documentation wasn't clear enough for me.

Note that when $WorkDirectory is not set or set to a non-writable location, the state file **will not be generated**.

  Am I wrong or state files are written to / in this scenario?

no, without a work directory set, they don't get written to /. As the doc says, they just don't get written anywhere.
This is not what is happening on my tests. Setting WorkDirectory to non-existing directory make it create imfile-state on /. Just opened an issue.

Regarding pollinginterval: During each polling interval, all files are processed in a round-robin fashion.

  I'm confused. Does this mean files are readed, sleep for X seconds,
  and readed again...
  or rsyslog reads documents during X seconds looping in a round-robin

the first.

readtimeout: This can be used with *startmsg.regex* (but not *readMode*)

  Why it can't be used with readmode? (Apart from obviously not

just not implemented (I actually expected that it would be implemented for readmodes)

read modes other than 0 currently seem to have issues in inotify mode

  Any open issues? it's an based-on-experienced-warning message? legacy?

good question

imfile has tag, facility and severity properties...

  Is there any way this properties being /inherited/ for ALL modules?
  (hence documented on "/input-modules/")

no, because other input modules don't hard-code these values, they set them based on the message they receive. It doesn't make sense to have them apply to all modules.
I don't understand your reasoning here.
Why it makes sense to set tag when using imfile but not with imtcp?

@radu-gheorghe @rgerhards could you have a look at https://github.com/mostolog/rsyslog-doc/blob/imfile/source/configuration/modules/imfile.rst

my comments

re: examples needed TODOs, are these items really needed? It seems to me that the explinations are pretty clear, I could see examples adding as much confusion as clarification.

re: windows/inode, this documentation is about the unix version. the windows version is slightly different (it has a GUI amoung other things), and it isn't free.

it's not always clear why you have TODO there. In most cases, the text following the TODO seems appropriate, could you change this to either put the description of what needs to change on it's own line, or otherwise indicate what needs to be changed?

I would group all the EXPERT options in one section, with the big warning at the top of them that if you don't understand them you should not set them.

I would also add a warning that they almost never need to be changed, even on high load systems, so benchmarks should be run before and after changing any of them because they sometimes have non-intuitive performance impact.

I would not set escapelf as an expert option, but rather make a grouping of options under the category "dealing with multi-line logs" and put it there along with readmode, regex.startmsg and the related timeouts.

trimlineoverbytes should actually apply to all modes, why only to some?
I'm just a monkey typing...ask someone who knows!

is reopen on truncate really still experimental?
It was marked so...

I would put the depriciated items in their own section.

Thank you a lot David.
rsyslog mailing list
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 

Reply via email to