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:[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
