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
fashion?
the first.
Thanks
readtimeout: This can be used with *startmsg.regex* (but not *readMode*)
Why it can't be used with readmode? (Apart from obviously not
implemented)
just not implemented (I actually expected that it would be implemented
for readmodes)
Ok
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
Rainer?
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.
Ok.
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.
Ok
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?
TODO=>WIP :P
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.
LGTM
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.
Ok.
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.
Done
Thank you a lot David.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
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
THAT.
