I would absolutely be willing to do that, but the file is 6.2 GB and even my access to the log server will barely allow me copy over that file to my machine (even when it is compressed - it is rather slow remote connection which will be auto-closed after a couple of MB, very secure, though...).
Can I somehow reduce the amount by e.g. sending you the first 10,000 lines and the last 10,000 lines? Ole -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Rainer Gerhards Gesendet: Freitag, 20. Mai 2011 15:38 An: rsyslog-users Betreff: Re: [rsyslog] Heavy stability problems when using TLS 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
