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.
