As a follow up. The segfaults appear to have been tied to the directive $WorkDirectory and the immark module somehow. When I removed them from the configuration the sigfaults appear to have gone away.
I will comment again if they manifest even after this change. -- James ________________________________________ From: [email protected] <[email protected]> on behalf of Boylan, James <[email protected]> Sent: Tuesday, August 12, 2014 8:43 AM To: rsyslog-users Subject: [rsyslog] rsyslog segfaults being experienced So I'm changing the Subject on this to be more accurate in the hope that someone else might have seen this behavior in the past. I admit that it has be somewhat stumped. I have many client side instances of rsyslog running that is collecting application longs then sending them to a central log server. However what I am finding is that many of these instances are segfaulting themselves to death. They end up in a state where they are running, act like everything is fine, but don't send any data anywhere. Doing a backtrace of the coredump being generated when rsyslog segfaults is showing the information below. The strange thing is that I'm still seeing this as being caused in linkedlist even after setting queue.type="Fixedarray" for all the actions and Rulesets then setting $MainMsgQueueType FixedArray for a global setting. Any thoughts? #0 llFindElt (pThis=0xf0, pKey=0x7f2a94000e70, ppData=0x7f2a94000a70) at linkedlist.c:293 #1 llFind (pThis=0xf0, pKey=0x7f2a94000e70, ppData=0x7f2a94000a70) at linkedlist.c:321 #2 0x00007f2a9bf1001c in MsgSetRulesetByName (pMsg=0x7f2a94000980, pStrm=0x7f2a9cb20ca0) at msg.c:377 #3 MsgDeserialize (pMsg=0x7f2a94000980, pStrm=0x7f2a9cb20ca0) at msg.c:1231 #4 0x00007f2a9bf18713 in objDeserializeWithMethods (ppObj=0x7f2a99812cb8, pszTypeExpected=0x7f2a9bf36b7b "msg", lenTypeExpected=3, pStrm=0x7f2a9cb20ca0, fFixup=0, pUsr=0x0, objConstruct=0x7f2a9bf10080 <msgConstructForDeserializer>, objConstructFinalize=0, objDeserialize=0x7f2a9bf0f800 <MsgDeserialize>) at obj.c:913 #5 0x00007f2a9bf22228 in qDeqDisk (pThis=<value optimized out>, ppMsg=<value optimized out>) at queue.c:923 #6 0x00007f2a9bf242f0 in qqueueDeq (pThis=0x7f2a9cb1cdd0, pWti=0x7f2a9cb1d190) at queue.c:1049 #7 DequeueConsumableElements (pThis=0x7f2a9cb1cdd0, pWti=0x7f2a9cb1d190) at queue.c:1601 #8 DequeueConsumable (pThis=0x7f2a9cb1cdd0, pWti=0x7f2a9cb1d190) at queue.c:1648 #9 0x00007f2a9bf248c3 in DequeueForConsumer (pThis=0x7f2a9cb1cdd0, pWti=<value optimized out>) at queue.c:1784 #10 ConsumerReg (pThis=0x7f2a9cb1cdd0, pWti=<value optimized out>) at queue.c:1838 #11 0x00007f2a9bf1fa06 in wtiWorker (pThis=0x7f2a9cb1d190) at wti.c:313 #12 0x00007f2a9bf1f4f2 in wtpWorker (arg=0x7f2a9cb1d190) at wtp.c:388 #13 0x00007f2a9b88e851 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f2a9a51b90d in clone () from /lib64/libc.so.6 -- James _______________________________________________ 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.
