2015-02-03 17:37 GMT+01:00 Rainer Gerhards <[email protected]>:
> 2015-02-03 17:31 GMT+01:00 David Lang <[email protected]>: > >> On Tue, 3 Feb 2015, Rainer Gerhards wrote: >> >> 2015-02-03 6:08 GMT+01:00 David Lang <[email protected]>: >>> >>> On Fri, 19 Sep 2014, David Lang wrote: >>>> >>>> On Fri, 19 Sep 2014, Masuda, Bond wrote: >>>> >>>>> >>>>> I'm seeing a lot of these types of logs entries: >>>>> >>>>>> >>>>>> Sep 19 16:45:26 server400 rsyslogd-2354: omfwd: error sending via udp: >>>>>> Resource temporarily unavailable [try http://www.rsyslog.com/e/2354 ] >>>>>> Sep 19 16:45:26 server400 rsyslogd0: action 'DataForwarding-NETASS' >>>>>> resumed (module 'builtin:omfwd') [try http://www.rsyslog.com/e/0 ] >>>>>> >>>>>> Running rsyslog-8.4.0-2.el6 RPM from rsyslog_v8 repo on RHEL 6.5 >>>>>> 64bit. >>>>>> >>>>>> Is there some resource exhausting happening on my system? Any help >>>>>> appreciated... >>>>>> >>>>>> >>>>> Probably, check for open files or the number of available ports >>>>> >>>>> >>>> I'm running into the same type of thing happening occasionally on my >>>> central logging server (running 8.7.0 currently) and so will be >>>> troubleshooting this more. >>>> >>>> >>>> Just a piece of information that may not be obvious: In messages like >>> this: >>> >>> Sep 19 16:45:26 server400 rsyslogd-2354: omfwd: error sending via udp: >>> Resource temporarily unavailable [tryhttp://www.rsyslog.com/e/2354 ] >>> >>> The actual error message (here: "Resource temporarily unavailable") is >>> taken directly from the system via (a variant of) strerror(), so it is >>> the >>> most precise one we can get. >>> >> >> That's what I figured, the problem is finding out what resource :-) >> >> I think it would be useful if it could say what it was doing when it got >> the error (opening the connection (probably filehandles) vs sending a >> packet (udp memory or something like that)) >> >> > I just checked the code, it's actually sendto(). But there's a BUT ;) If > there target resolves to multiple addresses (e.g. Ipv4/v6), sendto() is > called in a loop until success. If no success at all, the error message is > the last one, only. > > If you like, I can craft a patch for you (quickly done) that emits exact > errors on each send. But it's pretty specific, so before doing even a > trivial patch, let's see if that work would be useful at all... > > Interesting... I got curios which error code this is. So I tried strerror() on those that looked valid to me. This is the result: ENOBUFS: No buffer space available ENOMEM: Cannot allocate memory Maybe it's a good idea to output the errno itself into the message. This may be clearer... I'll craft a patch for that and would suggest that you apply it before testing. Rainer > Rainer > > >> Given the state of my system at the time, I'm betting on udp memory, but >> I'm trying to figure out how to measure that rather than just increasing it >> and seeing if this rare error goes away. >> >> >> David Lang >> _______________________________________________ >> 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. >> > > _______________________________________________ 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.
