humm...
I would not change it everywhere since I (personally) think it is a
pretty rare "problem" unles you have an applicatikon which usualy logs
very long messages.
What you are saying is use a .5Mb memory on all my servers just because
it "might be a long message" since very very long message (the message
data is several K's in size) are not too common in the eventlog I would
not change anything unless the error pops up.
// Michael Medin
Klaus Umbach skrev:
On 19/01/09 11:07, Michael Medin wrote:
It has nothing to do with language...
The reason is that one of them has an entry which is "too long" so you
need to update the buffer used when NSClinet++ reads the eventlog.
The simplest way to solve this is to increase the buffer_size variable
to something "large enough".
If you check the wiki/forums on nsclient.org you can find some "values
that worked for others" or you can play around and find what works for
you.
Thanks!
buffer_size=520000 worked. Now I have to change it everywhere... :-(
- Klaus
// Michael Medin
Klaus Umbach skrev:
Hi,
I wonder why the following check works on a German Windows 2k3 server, but
not on an English one. To me this makes no sense... NSC.ini is the same.
CheckEventLog filter=new file=application MaxWarn=1 MaxCrit=1
filter+generated=<2h filter==eventID=888
Errormessage: "EventlogBuffer is too small (set the value of buffer_size): 122 The
data area passed to a system call is too small."
NSClient++ Version: 0.3.5.1 2008-09-24 (32bit)
Maybe the language is just a coincidence...
Cheers
Klaus
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
