Hi Andre, I have the logs from the server side running 5.8.11 with 1.2.0 - can I send them as a gzipped attachment to you? I can redo them for the current version of rsyslog too if needed as well. One interesting thing that I found today is that if I restrict via iptables (or otherwise) just to one client that is sending logs via relp to the server, it actually works fine. Soon as I open it back up to other clients (~10 total), the server stops working on relp again.
Thanks, -Gene On Tue, Jul 23, 2013 at 5:39 AM, Andre Lorbach <[email protected]> wrote: > > Hi Gene, > > would it be possible to get a full debuglog? > I also would like to create a bug on our bugzilla and track the progress > there. > > My first guess is that there may be a problem with new and old relp > receiver and senders. > > Best regards, > Andre Lorbach > > > -----Original Message----- > > From: [email protected] [mailto:rsyslog- > > [email protected]] On Behalf Of Gene > > Sent: Monday, July 22, 2013 5:25 PM > > To: [email protected] > > Subject: Re: [rsyslog] RELP stops working after startup > > > > (Sorry for any broken threading, didn't get the original reply due to > > mistakenly setting digest) > > > > Unfortunately the issue persists with the same symptoms, even though the > > message spam is gone. Now the last lines are (after about 160 iterations > of > > the same): > > > > 5005.406661757:7f46b3eea700: relp engine is dispatching frame with > > command 'open' > > 5005.406679420:7f46b3eea700: processing client offer 'relp_software' > > 5005.406683271:7f46b3eea700: processing client offer 'relp_version' > > > > And stops there, 100% core usage, etc. > > > > This is also after compiling and running both librelp 1.2.0 and rsyslog > 7.5.2 as > > just upgrading librelp didn't help initially either. > > The clients are still running the older versions though, if that > matters. > > > > Thanks again, > > > > -Gene > > > > > Known and fixed bug. Upgrading librelp may be sufficient. > > > > > > Sent from phone, thus brief. > > > Am 19.07.2013 19:25 schrieb "Gene" <parakie at gmail.com>: > > > > > >> I'm having an odd issue on some 5.8.11 and 4.6.4 rsyslog servers when > > >> using imrelp. Here's the relevant config snippet: > > >> > > >> $ModLoad imrelp > > >> $InputrelpMaxSessions 5000 > > >> $InputRELPServerRun 20514 > > >> *.* ?hostsbydirectory;standardwithpri & ~ > > >> > > >> Essentially what happens is that on the restart of the rsyslog > > >> service it will accept a few lines worth of logs from some clients > > >> and then stop, while pegging a core at 100% cpu utilization. In this > > >> state it still accepts regular UDP and TCP syslog just fine. The odd > > >> part is that I have identically configured and versioned servers > > >> where I triple checked rsyslog config, sysctl parameters, etc, yet > the > > imrelp bits work just fine there. > > >> When running in debug mode, the only suspicious thing that I was able > > >> to see is that after the relp session starts, a few seconds later > > >> this > > >> happens: > > >> > > >> 1545.993749574:7f862941c700: tcpSend returns 105 > > >> 1545.993757082:7f862941c700: in destructor: sendbuf 0x1fb93a0 > > >> 1545.993767020:7f862941c700: relp engine is dispatching frame with > > >> command 'open' > > >> 1545.993774075:7f862941c700: in open command handler > > >> 1545.993783213:7f862941c700: processing client offer 'commands' > > >> 1545.993790284:7f862941c700: cmd syslog state in srv session: 4 > > >> 1545.993798094:7f862941c700: processing client offer 'relp_software' > > >> 1545.993805150:7f862941c700: processing client offer 'relp_version' > > >> 1545.993813183:7f862941c700: ConstructOffers syslog cmd state: 4 > > >> 1545.993825574:7f862941c700: tcpSend returns 3 > > >> 1545.993835129:7f862941c700: tcpSend returns 0 > > >> 1545.993844318:7f862941c700: tcpSend returns 0 > > >> > > >> The last line gets spammed a few thousand times per second after that > > >> with nothing else happening. This does not happen on the servers that > do > > work. > > >> So, I'm a bit lost on where to look next for troubleshooting, and > > >> would appreciate any thoughts on the matter. > > >> > > >> Thanks! > > >> > > >> -Gene > > _______________________________________________ > > 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. _______________________________________________ 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.
