The problem location may actually be far from the actual abort. Could you mail me the complete debug log?
Rainer > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Friday, May 20, 2011 3:26 PM > To: [email protected] > Subject: [rsyslog] Heavy stability problems when using TLS > > Hi Rainer, > > it will take me some time to set this up, but I guess that is the way to go... > > In the meantime syslog crashed while the debug log was running, but > unfortunately it seems like there is nothing interesting in there. > I still post it, just in case it tells you something... > > The core dump again contains "(...)ITICAL> Socket bind error, errno=50: > Cannot assign requested add(...)" > > Best regards > Ole > > > (...) > 5401.988709000:4: --------<NSDSEL_PTCP> calling select, active fds (max 36): 8 > 9 11 19 32 36 > 5401.988737200:4: hasRcvInBuffer on nsd 138268: pszRcvBuf 0, lenRcvBuf 0 > 5401.988745400:4: hasRcvInBuffer on nsd 856f0: pszRcvBuf 0, lenRcvBuf 0 > 5401.988753400:4: hasRcvInBuffer on nsd 160ff8: pszRcvBuf 6b9e28, > lenRcvBuf -1 > 5401.988761300:4: hasRcvInBuffer on nsd 177408: pszRcvBuf 1be080, > lenRcvBuf -1 > 5401.988768800:4: GnuTLS requested retry of 2 operation - executing > 5401.988776100:4: retrying gtls recv, nsd: 177408 > 5401.988785800:4: GnuTLS receive requires a retry (this most probably is OK > and no error condition) > 5401.988793900:4: gtlsRecordRecv return. nsd 177408, iRet -2100, lenRcvd -28, > lenRcvBuf -1, ptrRcvBuf 359 > 5401.988804900:4: hasRcvInBuffer on nsd 138268: pszRcvBuf 0, lenRcvBuf 0 > 5401.988812900:4: hasRcvInBuffer on nsd 856f0: pszRcvBuf 0, lenRcvBuf 0 > 5401.988820700:4: hasRcvInBuffer on nsd 160ff8: pszRcvBuf 6b9e28, > lenRcvBuf -1 > 5401.988828500:4: hasRcvInBuffer on nsd 177408: pszRcvBuf 1be080, > lenRcvBuf -1 > 5401.988836400:4: hasRcvInBuffer on nsd 15ecd0: pszRcvBuf 607150, > lenRcvBuf -1 > 5401.988844200:4: hasRcvInBuffer on nsd 1409a8: pszRcvBuf 1b9040, > lenRcvBuf -1 > 5401.988852100:4: --------<NSDSEL_PTCP> calling select, active fds (max 36): 8 > 9 11 19 32 36 > 5401.988880100:4: hasRcvInBuffer on nsd 138268: pszRcvBuf 0, lenRcvBuf 0 > 5401.988888300:4: hasRcvInBuffer on nsd 856f0: pszRcvBuf 0, lenRcvBuf 0 > 5401.988896300:4: hasRcvInBuffer on nsd 160ff8: pszRcvBuf 6b9e28, > lenRcvBuf -1 > 5401.988904300:4: hasRcvInBuffer on nsd 177408: pszRcvBuf 1be080, > lenRcvBuf -1 > 5401.988911700:4: GnuTLS requested retry of 2 operation - executing > 5401.988919000:4: retrying gtls recv, nsd: 177408 > 5401.988928700:4: GnuTLS receive requires a retry (this most probably is OK > and no error condition) > 5401.988936900:4: gtlsRecordRecv return. nsd 177408, iRet -2100, lenRcvd -28, > lenRcvBuf -1, ptrRcvBuf 359 > 5401.988947700:4: hasRcvInBuffer on nsd 138268: pszRcvBuf 0, lenRcvBuf 0 > 5401.988955700:4: hasRcvInBuffer on nsd 856f0: pszRcvBuf 0, lenRcvBuf 0 > 5401.988963500:4: hasRcvInBuffer on nsd 160ff8: pszRcvBuf 6b9e28, > lenRcvBuf -1 > 5401.988971300:4: hasRcvInBuffer on nsd 177408: pszRcvBuf 1be080, > lenRcvBuf -1 > 5401.988979100:4: hasRcvInBuffer on nsd 15ecd0: pszRcvBuf 607150, > lenRcvBuf -1 > 5401.988986900:4: hasRcvInBuffer on nsd 1409a8: pszRcvBuf 1b9040, > lenRcvBuf -1 > 5401.988994800:4: --------<NSDSEL_PTCP> calling select, active fds (max 36): 8 > 9 11 19 32 36 > 5401.989022800:4: hasRcvInBuffer on nsd 138268: pszRcvBuf 0, lenRcvBuf 0 > 5401.989031000:4: hasRcvInBuffer on nsd 856f0: pszRcvBuf 0, lenRcvBuf 0 > 5401.989038900:4: hasRcvInBuffer on nsd 160ff8: pszRcvBuf 6b9e28, > lenRcvBuf -1 > 5401.989046 > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:rsyslog- > [email protected]] Im Auftrag von Rainer Gerhards > Gesendet: Freitag, 20. Mai 2011 12:02 > An: rsyslog-users > Betreff: Re: [rsyslog] Heavy stability problems when using TLS > > I forgot to mention: > > > Well, I think the key thing is try to setup some lab where the crashes > happen > > as well. I guess it is either message-induced or induced by some > > issues in Solaris threading. Maybe it helps if you record traffic > > (from sufficient > > sources) and replay it against a Linux box. If that one crashes, we > > have > more > > options. If it does not crash, this does not directly point us to > something, > > unfortunately... > > What I am looking for is some better information on when the crash > happens. > So valgrind is often a good choice to check if there are some violations. Not > sure, though, if that's available on Solaris. > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
