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.
