I will look into this, strangely I couldn't reproduce the sigsegv on my test machine with the newstyle config.
Best regards, Andre > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of David Lang > Sent: Wednesday, July 24, 2013 1:17 AM > To: rsyslog-users > Subject: Re: [rsyslog] Segfault when using omsnmp > > This crys to me that the new style config parser is broken, and it's probably > trying to force setting some of these things that don't make sense with > SNMPv2. > > Andre would have to check into it, but that's where I would start looking. > > David Lang > > On Tue, 23 Jul 2013, Bryn Hughes wrote: > > > The "new style" config actually rejects the entire statement if those > > parts aren't entered, despite the documentation saying that they are > > optional, and the docs saying that some of them do not apply to SNMP > > v2 (which I am using). If I leave them out then I don't get a > > segfault, but rsyslogd doesn't actually send any SNMP traps since it > > rejects the configuration as missing required attributes. > > > > Adding all of those statements with their relative "legacy" config > > options works just fine here (though of course the 'traptype' and > > 'specifictype' fields have no effect on the output with SNMP v2). > > > > This works fine: > > > > # Load the Textfile input module and set polling interval to 10 seconds > > module(load="imfile" PollingInterval="10") > > > > # Load the SNMP module > > $ModLoad omsnmp > > > > # Default SNMP configuration > > $actionsnmptransport udp > > $actionsnmptarget 192.168.1.100 > > $actionsnmptargetport 162 > > $actionsnmpversion 1 > > $actionsnmpcommunity testtest > > $actionsnmptrapoid 1.3.6.1.4.1.19406.1.2.1 > > $actionsnmpsyslogmessageoid 1.3.6.1.4.1.19406.1.1.2.1 > > $actionsnmpenterpriseoid 1.3.6.1.4.1.3.1.1 > > $actionsnmptraptype 2 > > $actionsnmpspecifictype 0 > > > > # Test File > > input(type="imfile" File="/var/log/testlog" > > Tag="testapp1" > > StateFile="testlog") > > > > if $programname == 'testapp1' then { > > if $msg contains 'error' then { > > :omsnmp: > > } > > } > > > > > > As far as I can tell there is a bug in the parser for the new-style > > config, given that it works fine with the legacy stuff. > > > > I'm happy to continue helping troubleshoot the issue though my > > immediate needs are satisfied using the legacy style configuration. > > Strangely this problem seemed to be common even to rsyslog-6.6.0 so it > > may well have been lingering for quite a long time. I suppose there > > are not really that many people using SNMP alerts from rsyslog. > > > > I have filed a bug on the tracker so this can get looked at in the future: > > > > http://bugzilla.adiscon.com/show_bug.cgi?id=468 > > > > Bryn > > > > > > On 13-07-23 02:12 PM, David Lang wrote: > >> hmm, looking at the two configs, I see several things specified in > >> the new style config that aren't in the old config > >> > >> trapoid="1.3.6.1.4.1.19406.1.2.1" > >> messageoid="1.3.6.1.4.1.19406.1.1.2.1" > >> enterpriseoid="1.3.6.1.4.1.3.1.1" > >> traptype="6" > >> specifictype="0" > >> > >> you may want to try leaving these out of the new config or adding the > >> equivalent to the old config. > >> > >> David Lang > >> > >> On Tue, 23 Jul 2013, Bryn Hughes wrote: > >> > >>> Date: Tue, 23 Jul 2013 13:54:05 -0700 > >>> From: Bryn Hughes <[email protected]> > >>> Reply-To: rsyslog-users <[email protected]> > >>> To: [email protected] > >>> Subject: Re: [rsyslog] Segfault when using omsnmp > >>> > >>> OK, I'm making progress!! > >>> > >>> With this config things work: > >>> > >>> # Load the Textfile input module and set polling interval to 10 > >>> seconds > >>> module(load="imfile" PollingInterval="10") > >>> > >>> # Load the SNMP module > >>> $ModLoad omsnmp > >>> > >>> # Default SNMP configuration > >>> $actionsnmptransport udp > >>> $actionsnmptarget 192.168.1.100 > >>> $actionsnmptargetport 162 > >>> $actionsnmpversion 1 > >>> $actionsnmpcommunity sitatest > >>> > >>> # Test File > >>> input(type="imfile" File="/var/log/testlog" > >>> Tag="testapp1" > >>> StateFile="testlog") > >>> > >>> if $programname == 'testapp1' then :omsnmp: > >>> > >>> > >>> > >>> > >>> ....but if I do this instead: > >>> > >>> # Load the Textfile input module and set polling interval to 10 > >>> seconds > >>> module(load="imfile" PollingInterval="10") > >>> > >>> # Load the SNMP module > >>> $ModLoad omsnmp > >>> > >>> > >>> # Test File > >>> input(type="imfile" File="/var/log/testlog" > >>> Tag="testapp1" > >>> StateFile="testlog") > >>> > >>> if $programname == 'testapp1' then { > >>> action(type="omsnmp" > >>> transport="udp" > >>> server="192.168.1.100" > >>> port="162" > >>> version="1" > >>> community="sitatest" > >>> trapoid="1.3.6.1.4.1.19406.1.2.1" > >>> messageoid="1.3.6.1.4.1.19406.1.1.2.1" > >>> enterpriseoid="1.3.6.1.4.1.3.1.1" > >>> traptype="6" > >>> specifictype="0") > >>> ) > >>> } > >>> > >>> ...I get a segfault. > >>> > >>> So the issue is related to the particular format used for the > >>> configuration. If I specify it as action(type="omsnmp") I get a > >>> segfault, if I specify it as :omsnmp: then everything works perfectly. > >>> > >>> I guess this is a bug?? > >>> > >>> Bryn > >>> > >>> On 13-07-23 01:06 PM, Bryn Hughes wrote: > >>>> I also tried building everything from the SRPMs - still get the > >>>> same segfault so it is nothing to do with the prebuilt binaries. > >>>> > >>>> gdb says: > >>>> > >>>> Program terminated with signal 11, Segmentation fault. #0 > >>>> 0x00002b5befada02b in _int_free () from /lib64/libc.so.6 > >>>> > >>>> > >>>> Bryn > >>>> > >>>> On 13-07-23 09:48 AM, Bryn Hughes wrote: > >>>>> Hi Andre, > >>>>> > >>>>> I just retried on another RHEL5 machine. The first one was a > >>>>> local test VM on Virtualbox on my local laptop, this new test is > >>>>> on one of our corporate RHEL images so not even involving the same > >>>>> install media / storage / virtualization or anything... Issue > >>>>> still occurs so I don't believe it is related to the net-snmp > >>>>> libraries unfortunately (unless there is a bug in rsyslogd in how > >>>>> it talks to the libraries) > >>>>> > >>>>> I started it with valgrind, this is what it came back with: > >>>>> > >>>>> ==10125== Memcheck, a memory error detector ==10125== > Copyright > >>>>> (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. > >>>>> ==10125== Using Valgrind-3.5.0 and LibVEX; rerun with -h for > >>>>> copyright info ==10125== Command: /sbin/rsyslogd -i > >>>>> /var/run/rsyslogd.pid ==10125== ==10125== Invalid free() / delete > >>>>> / delete[] > >>>>> ==10125== at 0x4A05D21: free (vg_replace_malloc.c:325) > >>>>> ==10125== by 0x13E8D4: OMSRdestruct (in /sbin/rsyslogd) > >>>>> ==10125== by 0x15657D: addAction (in /sbin/rsyslogd) > >>>>> ==10125== by 0x156922: actionNewInst (in /sbin/rsyslogd) > >>>>> ==10125== by 0x12A889: cnfstmtNewAct (in /sbin/rsyslogd) > >>>>> ==10125== by 0x12606B: yyparse (in /sbin/rsyslogd) > >>>>> ==10125== by 0x135E5C: load (in /sbin/rsyslogd) > >>>>> ==10125== by 0x11A8D3: realMain (in /sbin/rsyslogd) > >>>>> ==10125== by 0x5A8C9C3: (below main) (in /lib64/libc-2.5.so) > >>>>> ==10125== Address 0x6838cc0 is not stack'd, malloc'd or > >>>>> (recently) free'd ==10125== ==10125== Warning: noted but > unhandled > >>>>> ioctl 0x5422 with no size/direction hints > >>>>> ==10125== This could cause spurious value errors to appear. > >>>>> ==10125== See README_MISSING_SYSCALL_OR_IOCTL for guidance > on > >>>>> writing > >>>>> a proper wrapper. > >>>>> ==10125== > >>>>> ==10125== HEAP SUMMARY: > >>>>> ==10125== in use at exit: 95,290 bytes in 1,495 blocks > >>>>> ==10125== total heap usage: 2,119 allocs, 625 frees, 159,459 bytes > >>>>> allocated > >>>>> ==10125== > >>>>> ==10125== LEAK SUMMARY: > >>>>> ==10125== definitely lost: 0 bytes in 0 blocks > >>>>> ==10125== indirectly lost: 0 bytes in 0 blocks > >>>>> ==10125== possibly lost: 7,604 bytes in 47 blocks > >>>>> ==10125== still reachable: 87,686 bytes in 1,448 blocks > >>>>> ==10125== suppressed: 0 bytes in 0 blocks > >>>>> ==10125== Rerun with --leak-check=full to see details of leaked > >>>>> memory ==10125== ==10125== For counts of detected and > suppressed > >>>>> errors, rerun with: -v ==10125== ERROR SUMMARY: 1 errors from 1 > >>>>> contexts (suppressed: 27 from 7) > >>>>> > >>>>> > >>>>> On 13-07-23 07:16 AM, Andre Lorbach wrote: > >>>>>> Hi Bryn, > >>>>>> > >>>>>> would it be possible for your to run rsyslog with valgrind? > >>>>>> This would be very helpful. > >>>>>> > >>>>>> I just have run a short test with your config snipset on my > >>>>>> testmachine, and it works well and is sending snmp traps. > >>>>>> So my guess is that there is something wrong with the net snmp > >>>>>> libraries, or something is missing. > >>>>>> > >>>>>> Best regards, > >>>>>> Andre Lorbach > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: [email protected] [mailto:rsyslog- > >>>>>>> [email protected]] On Behalf Of Bryn Hughes > >>>>>>> Sent: Tuesday, July 23, 2013 1:40 AM > >>>>>>> To: rsyslog-users > >>>>>>> Subject: Re: [rsyslog] Segfault when using omsnmp > >>>>>>> > >>>>>>> Thanks David, > >>>>>>> > >>>>>>> I've posted the full debug output here: > >>>>>>> > >>>>>>> http://pastebin.com/nDzmiUxV > >>>>>>> > >>>>>>> There is nothing that immediately jumps out at me - no "missing > >>>>>>> library version blah" or anything like that... I confirmed that > >>>>>>> the system has > >>>>>> net- > >>>>>>> snmp-libs installed, plus tried both the version off of the > >>>>>>> original > >>>>>> RHEL CD plus > >>>>>>> the "current" one (which is 5.3.2.2-20.el5)... I'm not sure if > >>>>>>> there are > >>>>>> any > >>>>>>> other libs I should be looking for. > >>>>>>> > >>>>>>> The last portion of the debug output: > >>>>>>> > >>>>>>> 0782.367445000:2b39f255e290: action 1 queue: parameter dump: > >>>>>>> 0782.367610000:2b39f255e290: action 1 queue: queue.filename > '[NONE]' > >>>>>>> 0782.367843000:2b39f255e290: action 1 queue: queue.size: 1000 > >>>>>>> 0782.368110000:2b39f255e290: action 1 queue: > queue.dequeuebatchsize: > >>>>>>> 128 > >>>>>>> 0782.368329000:2b39f255e290: action 1 queue: > queue.maxdiskspace: > >>>>>>> 1048576 > >>>>>>> 0782.368476000:2b39f255e290: action 1 queue: > queue.highwatermark: > >>>>>>> 800 > >>>>>>> 0782.368828000:2b39f255e290: action 1 queue: > queue.lowwatermark: > >>>>>>> 200 > >>>>>>> 0782.369020000:2b39f255e290: action 1 queue: > >>>>>>> queue.fulldelaymark: -1 > >>>>>>> 0782.369334000:2b39f255e290: action 1 queue: > >>>>>>> queue.lightdelaymark: -1 > >>>>>>> 0782.369512000:2b39f255e290: action 1 queue: queue.discardmark: > >>>>>>> 980 > >>>>>>> 0782.369686000:2b39f255e290: action 1 queue: > >>>>>>> queue.discardseverity: 8 > >>>>>>> 0782.369896000:2b39f255e290: action 1 queue: > >>>>>>> queue.checkpointinterval: 0 > >>>>>>> 0782.370074000:2b39f255e290: action 1 queue: > >>>>>>> queue.syncqueuefiles: 0 > >>>>>>> 0782.370266000:2b39f255e290: action 1 queue: queue.type: 3 > >>>>>>> [Direct] > >>>>>>> 0782.370384000:2b39f255e290: action 1 queue: > >>>>>>> queue.workerthreads: 1 > >>>>>>> 0782.370556000:2b39f255e290: action 1 queue: > >>>>>>> queue.timeoutshutdown: 0 > >>>>>>> 0782.370736000:2b39f255e290: action 1 queue: > >>>>>>> queue.timeoutactioncompletion: 1000 > >>>>>>> 0782.370910000:2b39f255e290: action 1 queue: > queue.timeoutenqueue: > >>>>>>> 2000 > >>>>>>> 0782.371112000:2b39f255e290: action 1 queue: > >>>>>>> queue.timeoutworkerthreadshutdown: 60000 > >>>>>>> 0782.371348000:2b39f255e290: action 1 queue: > >>>>>>> queue.workerthreadminimummessages: 100 > >>>>>>> 0782.371474000:2b39f255e290: action 1 queue: queue.maxfilesize: > >>>>>>> 1048576 > >>>>>>> 0782.371724000:2b39f255e290: action 1 queue: > >>>>>>> queue.saveonshutdown: 1 > >>>>>>> 0782.371876000:2b39f255e290: action 1 queue: > >>>>>>> queue.dequeueslowdown: 0 > >>>>>>> 0782.372128000:2b39f255e290: action 1 queue: > >>>>>>> queue.dequeuetimebegin: 0 > >>>>>>> 0782.372263000:2b39f255e290: action 1 queue: > >>>>>>> queuedequeuetimend.: 25 > >>>>>>> 0782.372377000:2b39f255e290: Action 0x2b39f34d50c0: queue > >>>>>>> 0x2b39f34d5710 created Segmentation fault > >>>>>>> > >>>>>>> Bryn > >>>>>>> > >>>>>>> On 13-07-22 04:16 PM, David Lang wrote: > >>>>>>>> If you try to start rsyslog with the -dn options, does it tell > >>>>>>>> you anything interesting when it segfaults? > >>>>>>>> > >>>>>>>> My guess is that you are missing the snmp library that it's > >>>>>>>> trying to access, but I think the debug output would make it > >>>>>>>> very clear. > >>>>>>>> > >>>>>>>> David Lang > >>>>>>>> > >>>>>>>> On Mon, 22 Jul 2013, Bryn Hughes wrote: > >>>>>>>> > >>>>>>>>> Hi there, > >>>>>>>>> > >>>>>>>>> We need to be able to send SNMP traps based on certain log > >>>>>>>>> messages. > >>>>>>>>> rsyslog looks to be able to do exactly what I need, however it > >>>>>>>>> is segfaulting on me if I try and start it with an SNMP > >>>>>>>>> configuration. > >>>>>>>>> > >>>>>>>>> Here is my brutally simple SNMP config: > >>>>>>>>> > >>>>>>>>> # Load the SNMP module > >>>>>>>>> $ModLoad omsnmp > >>>>>>>>> > >>>>>>>>> if $msg contains 'error' then { action(type="omsnmp" > >>>>>>>>> transport="udp" > >>>>>>>>> server="192.168.1.1" > >>>>>>>>> port="162" > >>>>>>>>> version="1" > >>>>>>>>> community="testtest" > >>>>>>>>> trapoid="1.3.6.1.4.1.19406.1.2.1" > >>>>>>>>> messageoid="1.3.6.1.4.1.19406.1.1.2.1" > >>>>>>>>> enterpriseoid="1.3.6.1.4.1.3.1.1" > >>>>>>>>> traptype="6" > >>>>>>>>> specifictype="0") > >>>>>>>>> } > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On an entirely different note, the docs aren't really accurate for > >>>>>>>>> this as most of those config statements are identified as > >>>>>>>>> "optional" > >>>>>>>>> in the documentation, yet the software will ignore the entire > >>>>>>>>> action > >>>>>>>>> if they aren't present. If it passes the config validator though > >>>>>>>>> then I get a segfault on startup... > >>>>>>>>> > >>>>>>>>> Starting system logger: /bin/bash: line 1: 15332 Segmentation > >>>>>>>>> fault > >>>>>>>>> /sbin/rsyslogd -i /var/run/rsyslogd.pid > >>>>>>>>> [FAILED] > >>>>>>>>> > >>>>>>>>> I have tested with 7.2.7, 7.4.2 and 7.4.3 - all versions had > >>>>>>>>> the same > >>>>>>>>> behavior on my RHEL5 x86_64 test system. > >>>>>>>>> > >>>>>>>>> Assistance greatly appreciated!! > >>>>>>>>> > >>>>>>>>> Bryn > >>>>>>>>> _______________________________________________ > > > > _______________________________________________ > > 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.
