Hi all,
as mentioned in some past posts, omfile did not really care if log data made
it into the file system. The overall reaction was "don't care, discard
message".
I have now improved the situation very much (at least I hope so ;)). There is
currently an experimental git branch omfile-errHandler which properly
suspends the action if something goes wrong. The only thing it currently does
not do is truncate partially written lines. I'll save this for some later
release when I revamp to module as whole.
I plan to merge this change into the main development branch soon and then do
a new devel release. If you would like to play with the current version, I of
course would appreciate that. If so, please let me know your results.
Also, I found one strange thing while testing with the cifs (SMB) handler. It
does not properly return a failure state, so I currently have no clue how to
detect a failure condition in that case. Below, I post some excerpt from a
forum thread related to the work [1]. If you happen to have any suggestions,
please let me know.
=====
good news and bad news: I have found a bug inside the code, and been able to
fix that (not yet committed). However, I tried with the smb redirector (don't
have nfs at hand) and it acks the writes, but does not ensure data is
actually put onto the remote site. So there probably is no way to make sure
we really have the data. Maybe the situation is better with NFS.
below some excerpts from my twitter stream:
# i have lots of garbage inside the log when I reconnect the network... looks
like cifs driver can not really handle this situation1 minute ago from twhirl
# it is interesting to see how the smb driver continues to accept data (at a
very slow rate) while the network is off....9 minutes ago from twhirl
# #rsyslog: issue is more complicated than I thought - probably a bug in
dynafile creation processabout 1 hour ago from twhirl
# ok, think I got a bug. FD is not set to indicated "closed" after actual
close call - can lead to endless loopabout 2 hours ago from twhirl
# as soon as I enter a new message, the missing content *is* writtenabout 2
hours ago from twhirl
# after disconnect, nothing is written...about 2 hours ago from twhirl
# very interesting... I get successful returns from write() to the network
file - with plugged cable, lazy write, I guess...about 2 hours ago from
twhirl
# #rsyslog: OS buffering plays a big role in network-file retries - on the
initial tries I do not see any error code at all! (w/o cable!!)about 2 hours
ago from twhirl
====
Thanks,
Rainer
[1]
http://kb.monitorware.com/log-to-nfs-and-buffer-if-unavailable-t8963-30.html#
p15732
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
as mentioned in some past posts, omfile did not really care if log data made
it into the file system. The overall reaction was "don't care, discard
message".
I have now improved the situation very much (at least I hope so ;)). There is
currently an experimental git branch omfile-errHandler which properly
suspends the action if something goes wrong. The only thing it currently does
not do is truncate partially written lines. I'll save this for some later
release when I revamp to module as whole.
I plan to merge this change into the main development branch soon and then do
a new devel release. If you would like to play with the current version, I of
course would appreciate that. If so, please let me know your results.
Also, I found one strange thing while testing with the cifs (SMB) handler. It
does not properly return a failure state, so I currently have no clue how to
detect a failure condition in that case. Below, I post some excerpt from a
forum thread related to the work [1]. If you happen to have any suggestions,
please let me know.
=====
good news and bad news: I have found a bug inside the code, and been able to
fix that (not yet committed). However, I tried with the smb redirector (don't
have nfs at hand) and it acks the writes, but does not ensure data is
actually put onto the remote site. So there probably is no way to make sure
we really have the data. Maybe the situation is better with NFS.
below some excerpts from my twitter stream:
# i have lots of garbage inside the log when I reconnect the network... looks
like cifs driver can not really handle this situation1 minute ago from twhirl
# it is interesting to see how the smb driver continues to accept data (at a
very slow rate) while the network is off....9 minutes ago from twhirl
# #rsyslog: issue is more complicated than I thought - probably a bug in
dynafile creation processabout 1 hour ago from twhirl
# ok, think I got a bug. FD is not set to indicated "closed" after actual
close call - can lead to endless loopabout 2 hours ago from twhirl
# as soon as I enter a new message, the missing content *is* writtenabout 2
hours ago from twhirl
# after disconnect, nothing is written...about 2 hours ago from twhirl
# very interesting... I get successful returns from write() to the network
file - with plugged cable, lazy write, I guess...about 2 hours ago from
twhirl
# #rsyslog: OS buffering plays a big role in network-file retries - on the
initial tries I do not see any error code at all! (w/o cable!!)about 2 hours
ago from twhirl
====
Thanks,
Rainer
[1]
http://kb.monitorware.com/log-to-nfs-and-buffer-if-unavailable-t8963-30.html#
p15732
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com