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... 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.
