Package: rsyslog; Maintainer for rsyslog is Michael Biebl <biebl@debian.org>; Source for rsyslog is src:rsyslog (PTS, buildd, popcon).
Reported by: Christoph Martin <martin@uni-mainz.de>
Date: Thu, 1 Oct 2009 06:42:01 UTC
Severity: important
Found in version 4.2.0-1~bpo50+1
Fixed in version rsyslog/4.6.4-2
Done: Michael Biebl <biebl@debian.org>
Bug is archived. No further changes may be made.
Forwarded to http://bugzilla.adiscon.com/show_bug.cgi?id=194
View this report as an mbox folder, status mbox, maintainer mbox
Report forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Thu, 01 Oct 2009 06:42:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Christoph Martin <martin@uni-mainz.de>:
New Bug report received and forwarded. Copy sent to Michael Biebl <biebl@debian.org>.
(Thu, 01 Oct 2009 06:42:04 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
Package: rsyslog Version: 4.2.0-1~bpo50+1 Severity: important I use the syslog-tls feature to send syslog messages from a bunch of host to a centralized rsyslog server. On initial startup of rsyslog on the syslog server it consumes allready about 170M. If I only have one client which sends syslog messages it stays like this. But when I start the syslogs senders on one to three other host, the memory quickly (in minutes) goes up to 2G. The machine then goes in to swapping and is mostly unusable. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rsyslog depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages rsyslog recommends: ii logrotate 3.7.1-5 Log rotation utility Versions of packages rsyslog suggests: pn rsyslog-doc <none> (no description available) ii rsyslog-gnutls 4.2.0-1~bpo50+1 TLS protocol support for rsyslog pn rsyslog-gssapi <none> (no description available) pn rsyslog-mysql | rsyslog- <none> (no description available) pn rsyslog-relp <none> (no description available) -- no debconf information -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rsyslog depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages rsyslog recommends: ii logrotate 3.7.1-5 Log rotation utility Versions of packages rsyslog suggests: pn rsyslog-doc <none> (no description available) ii rsyslog-gnutls 4.2.0-1~bpo50+1 TLS protocol support for rsyslog pn rsyslog-gssapi <none> (no description available) pn rsyslog-mysql | rsyslog- <none> (no description available) pn rsyslog-relp <none> (no description available) -- no debconf information
Information forwarded
to debian-bugs-dist@lists.debian.org:
Bug#549168; Package rsyslog.
(Fri, 02 Oct 2009 05:03:05 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list.
(Fri, 02 Oct 2009 05:03:05 GMT) (full text, mbox, link).
Message #10 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Christoph Martin wrote: > Package: rsyslog > Version: 4.2.0-1~bpo50+1 > Severity: important > > > I use the syslog-tls feature to send syslog messages from a bunch of host > to a centralized rsyslog server. On initial startup of rsyslog on > the syslog server it consumes allready about 170M. If I only have one > client which sends syslog messages it stays like this. But when I > start the syslogs senders on one to three other host, the memory > quickly (in minutes) goes up to 2G. The machine then goes in to > swapping and is mostly unusable. > Hi Christoph, could you please attach the configuration you use on the client and server. How do you messure the RAM usage? What kind of throughput (messages/min) do you have? Does the rsyslog server maybe have problems to write the messages to disk and so buffers them in memory. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Fri, 02 Oct 2009 06:24:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Christoph Martin <martin@uni-mainz.de>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Fri, 02 Oct 2009 06:24:03 GMT) (full text, mbox, link).
Message #15 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Michael, Michael Biebl schrieb: > > Hi Christoph, > > could you please attach the configuration you use on the client and server. Files are attached. master is the server. m1234 and yoda are clients. local conf is a configuration in /etc/rsyslog.d/ > How do you messure the RAM usage? Output of top. If I start rsyslog on master with only m1234 as client it immediatly goes to 143m in top. If I start the client on yoda, it continually grows to 2,5G in minutes. > What kind of throughput (messages/min) do you have? master itself has about 1400 lines with 20kb a day. m1234 brings about 10000 lines with 150kb a day. yoda has about 4300 lines with 65kb a day. Which is not really much. > Does the rsyslog server > maybe have problems to write the messages to disk and so buffers them in memory. I just found out that the logrotation is not automatically configured to different logfiles like it was in plain old sysklogd. So my syslog.all file on master has about 134M which would account for the initial size of rsyslog on this host. But does rsyslog really have to load the whole file into memory in order to append new messages? And it is still a question why it grows to more that 2G after a while with more hat one client. And no, it has no problems writing to disk. Christoph
[local.conf.yoda (text/plain, inline)]
mail,local0.debug /var/log/syslog.mail.debug auth.debug /var/log/syslog.auth.debug cron.debug /var/log/syslog.cron.debug *.debug;mail,auth,cron,local0.none /var/log/syslog.debug *.info;mail,auth,cron,local0.none /var/log/syslog.info *.notice;mail,auth,cron,local0.none /var/log/syslog.notice *.warning /var/log/syslog.warning *.* /var/log/syslog.all *.emerg * *.warning /dev/console *.alert root #*.debug @master.m1234.de #*.* @@(o)master.m1234.de:10514 # send (all) messages
[rsyslog.conf.yoda (text/plain, inline)]
# /etc/rsyslog.conf Configuration file for rsyslog v3. # # For more information see # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html ################# #### MODULES #### ################# $ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 # certificate files - just CA for a client $DefaultNetstreamDriverCAFile /etc/rsyslog.d/ca.pem # set up the action $DefaultNetstreamDriver gtls # use gtls netstream driver $ActionSendStreamDriverMode 1 # require TLS for the connection $ActionSendStreamDriverAuthMode anon # server is NOT authenticated ########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Logging for INN news system. # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice # # Some "catch-all" log files. # *.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg * # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # # $ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole
[local.conf.m1234 (text/plain, inline)]
mail,local0.debug /var/log/syslog.mail.debug auth.debug /var/log/syslog.auth.debug cron.debug /var/log/syslog.cron.debug *.debug;mail,auth,cron,local0.none /var/log/syslog.debug *.info;mail,auth,cron,local0.none /var/log/syslog.info *.notice;mail,auth,cron,local0.none /var/log/syslog.notice *.warning /var/log/syslog.warning *.* /var/log/syslog.all *.emerg * *.warning /dev/console *.alert root #*.debug @master.m1234.de *.* @@(o)master.m1234.de:10514 # send (all) messages
[rsyslog.conf.m1234 (text/plain, inline)]
# /etc/rsyslog.conf Configuration file for rsyslog v3. # # For more information see # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html ################# #### MODULES #### ################# $ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 # certificate files - just CA for a client $DefaultNetstreamDriverCAFile /etc/rsyslog.d/ca.pem # set up the action $DefaultNetstreamDriver gtls # use gtls netstream driver $ActionSendStreamDriverMode 1 # require TLS for the connection $ActionSendStreamDriverAuthMode anon # server is NOT authenticated ########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Logging for INN news system. # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice # # Some "catch-all" log files. # *.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg * # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # # $ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole
[local.conf.master (text/plain, inline)]
mail,local0.debug /var/log/syslog.mail.debug auth.debug /var/log/syslog.auth.debug cron.debug /var/log/syslog.cron.debug *.debug;mail,auth,cron,local0.none /var/log/syslog.debug *.info;mail,auth,cron,local0.none /var/log/syslog.info *.notice;mail,auth,cron,local0.none /var/log/syslog.notice *.warning /var/log/syslog.warning *.* /var/log/syslog.all *.emerg * *.warning /dev/console *.alert root
[rsyslog.conf.master (text/plain, inline)]
# /etc/rsyslog.conf Configuration file for rsyslog v3. # # For more information see # /usr/share/doc/rsyslog-doc/html/rsyslog_conf.html ################# #### MODULES #### ################# #$MainMessageQueueSize 512 $ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # make gtls driver the default $DefaultNetstreamDriver gtls # certificate files $DefaultNetstreamDriverCAFile /etc/rsyslog.d/ca.pem $DefaultNetstreamDriverCertFile /etc/rsyslog.d/cert.pem $DefaultNetstreamDriverKeyFile /etc/rsyslog.d/key.pem $ModLoad imtcp # load TCP listener $InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode $InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated $InputTCPServerRun 10514 # start up listener at port 10514 # provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 ########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Set the default permissions for all log files. # $FileOwner root $FileGroup adm $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Include all config files in /etc/rsyslog.d/ # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Logging for INN news system. # news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice -/var/log/news/news.notice # # Some "catch-all" log files. # *.=debug;\ auth,authpriv.none;\ news.none;mail.none -/var/log/debug *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages # # Emergencies are sent to everybody logged in. # *.emerg * # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 # The named pipe /dev/xconsole is for the `xconsole' utility. To use it, # you must invoke `xconsole' with the `-file' option: # # $ xconsole -file /dev/xconsole [...] # # NOTE: adjust the list below, or you'll go crazy if you have a reasonably # busy site.. # daemon.*;mail.*;\ news.err;\ *.=debug;*.=info;\ *.=notice;*.=warn |/dev/xconsole
[martin.vcf (text/x-vcard, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Fri, 02 Oct 2009 07:57:08 GMT) (full text, mbox, link).
Acknowledgement sent
to Christoph Martin <martin@uni-mainz.de>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Fri, 02 Oct 2009 07:57:08 GMT) (full text, mbox, link).
Message #20 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Christoph Martin schrieb: > I just found out that the logrotation is not automatically configured to > different logfiles like it was in plain old sysklogd. So my syslog.all > file on master has about 134M which would account for the initial size > of rsyslog on this host. But does rsyslog really have to load the whole > file into memory in order to append new messages? And it is still a > question why it grows to more that 2G after a while with more hat one > client. And no, it has no problems writing to disk. Hmm. Coincidence. I rotated the files and restart rsyslog with empty logfiles and it still comes up with ~140M.
[martin.vcf (text/x-vcard, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Tue, 17 Nov 2009 02:57:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Marcin Szewczyk <Marcin.Szewczyk@wodny.org>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Tue, 17 Nov 2009 02:57:06 GMT) (full text, mbox, link).
Message #25 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi there, I'm experiencing the same or a similar problem. There really seams to be an issue with TLS. I attach the debug output. One file, when memory starts to disappear and another, 1 million debug lines and 30MB of RAM later, when everything but RAM comes back to normal. -- Marcin Szewczyk http://wodny.org mailto:Marcin.Szewczyk@wodny.borg <- remove b / usuń b xmpp:wodny@ubuntu.pl xmpp:wodny@jabster.pl
[rsyslog_weird_end.txt (text/plain, inline)]
HERE IS LINE 2341969 (2 351 969) 4541.729294028:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4541.729351140:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.729371182:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.729390866:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4541.729409450:imtcp.c: GnuTLS requested retry of 2 operation - executing 4541.729427824:imtcp.c: retrying gtls recv, nsd: 0x9d38b70 4541.729448358:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4541.729467885:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 89 4541.729490463:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.729510332:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.729529836:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4541.729549440:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4541.729569057:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4541.729625670:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.729645119:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.729664468:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4541.729683024:imtcp.c: GnuTLS requested retry of 2 operation - executing 4541.729701647:imtcp.c: retrying gtls recv, nsd: 0x9d38b70 4541.729721996:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4541.729741684:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 89 4541.729764303:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.729783720:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.729802894:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4541.729822767:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4541.729842394:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4541.729945511:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.729989028:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.730013921:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4541.730033167:imtcp.c: GnuTLS requested retry of 2 operation - executing 4541.730051610:imtcp.c: retrying gtls recv, nsd: 0x9d38b70 4541.730249564:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet 0, lenRcvd 90, lenRcvBuf 90, ptrRcvBuf 0 4541.730271523:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4541.730291205:imtcp.c: netstream 0x9d355e8 with new data 4541.730360183:imtcp.c: gtlsRecordRecv return. nsd 0x9d2f700, iRet 0, lenRcvd 149, lenRcvBuf 149, ptrRcvBuf 0 4541.730381612:imtcp.c: gtlsRcv return. nsd 0x9d2f700, iRet 0, lenRcvBuf -1, ptrRcvBuf 149 4541.730418028:imtcp.c: main queue: entry added, size now 1 entries 4541.730444421:imtcp.c: wtpAdviseMaxWorkers signals busy 4541.730495034:main queue:Reg/w0: main queue: entry deleted, state 0, size now 0 entries 4541.730525799:main queue:Reg/w0: msg parser: flags 30, from 'phb.student.pw.edu.pl', msg '<13>Nov 17 03:21:57 localhost phb-nagios: PROCESS_SERVICE_CHECK_RESULT;babilon-a-9;Port Transfer Monitor;0;PTM | 49:spd:1000:in:637386:out:1756270:;' 4541.730558946:main queue:Reg/w0: Message has legacy syslog format. 4541.730590901:main queue:Reg/w0: Filter: check for property 'programname' (value 'phb-nagios') isequal 'mac-notification': FALSE 4541.730619382:main queue:Reg/w0: Filter: check for property 'programname' (value 'phb-nagios') isequal 'phb-nagios': TRUE 4541.730648471:main queue:Reg/w0: Called action, logging to builtin-file 4541.730667890:main queue:Reg/w0: action 3 queue: entry added, size now 1 entries 4541.730693175:main queue:Reg/w0: wtpAdviseMaxWorkers signals busy 4541.730715344:main queue:Reg/w0: action 3 queue: EnqueueMsg advised worker start 4541.730751790:action 3 queue:Reg/w0: action 3 queue: entry deleted, state 0, size now 0 entries 4541.730782317:action 3 queue:Reg/w0: (/var/log/network-management/nagios3/from_syslog) 4541.731051824:action 3 queue:Reg/w0: action 3 queue:Reg/w0: worker IDLE, waiting for work. 4541.731094342:main queue:Reg/w0: Called action, logging to builtin-discard 4541.731115248:main queue:Reg/w0: 4541.731138795:main queue:Reg/w0: main queue:Reg/w0: worker IDLE, waiting for work. 4541.731165258:imtcp.c: main queue: EnqueueMsg advised worker start 4541.731534251:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.731555357:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.731575235:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf 90 4541.731594710:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4541.731615043:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4541.731634273:imtcp.c: New connect on NSD 0x9d38c88. 4541.731678043:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4541.731697647:imtcp.c: New connect on NSD 0x9d38dd0. 4541.731723680:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf 90 4541.731743152:imtcp.c: netstream 0x9d2e140 with new data 4541.731763584:imtcp.c: gtlsRcv return. nsd 0x9d38b70, iRet 0, lenRcvBuf -1, ptrRcvBuf 90 4541.731791189:imtcp.c: main queue: entry added, size now 1 entries 4541.731817569:imtcp.c: wtpAdviseMaxWorkers signals busy
[rsyslog_weird_start.txt (text/plain, inline)]
4506.225664442:main queue:Reg/w0: Called action, logging to builtin-discard 4506.225685314:main queue:Reg/w0: 4506.225708514:main queue:Reg/w0: main queue:Reg/w0: worker IDLE, waiting for work. 4506.225734077:imtcp.c: main queue: EnqueueMsg advised worker start 4506.225769520:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.225790067:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.225809728:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.225829644:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4506.225849684:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4506.225908415:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.225928333:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.225947981:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.225967293:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4506.225986314:imtcp.c: netstream 0x9d355e8 with new data 4506.226017561:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4506.226037932:imtcp.c: gtlsRecordRecv return. nsd 0x9d2f700, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 574 4506.226057370:imtcp.c: gtlsRcv return. nsd 0x9d2f700, iRet -2100, lenRcvBuf -1, ptrRcvBuf 574 4506.226081957:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.226101761:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.226121273:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.226140752:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4506.226160399:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4506.230339683:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.230417358:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.230438856:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.230458731:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4506.230477401:imtcp.c: GnuTLS requested retry of 2 operation - executing 4506.230496244:imtcp.c: retrying gtls recv, nsd: 0x9d2f700 4506.230628998:imtcp.c: gtlsRecordRecv return. nsd 0x9d2f700, iRet 0, lenRcvd 613, lenRcvBuf 613, ptrRcvBuf 0 4506.230663513:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.230683482:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.230703018:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.230722736:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf 613 4506.230742529:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.230761836:imtcp.c: New connect on NSD 0x9d38c88. 4506.230812219:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.230832154:imtcp.c: New connect on NSD 0x9d38dd0. 4506.230859060:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.230878897:imtcp.c: netstream 0x9d2e140 with new data 4506.230902498:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4506.230922542:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 89 4506.230942215:imtcp.c: gtlsRcv return. nsd 0x9d38b70, iRet -2100, lenRcvBuf -1, ptrRcvBuf 89 4506.230962046:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf 613 4506.230981300:imtcp.c: netstream 0x9d355e8 with new data 4506.231003968:imtcp.c: gtlsRcv return. nsd 0x9d2f700, iRet 0, lenRcvBuf -1, ptrRcvBuf 613 4506.231039533:imtcp.c: main queue: entry added, size now 1 entries 4506.231089344:imtcp.c: wtpAdviseMaxWorkers signals busy 4506.231152631:main queue:Reg/w0: main queue: entry deleted, state 0, size now 0 entries 4506.231184015:main queue:Reg/w0: msg parser: flags 30, from 'phb.student.pw.edu.pl', msg '<13>Nov 17 03:21:47 localhost phb-nagios: PROCESS_SERVICE_CHECK_RESULT;babilon-a;Port Transfer Monitor;0;PTM | 10101:spd:1000:in:318815:out:3620221:;10102:spd:1000:in:1840586:out:2684876:;10103:spd:1000:in:4015927:out:2334458:;10104:spd:1000:in:1076178:out:1566114:;10105:spd:1000:in:4058801:out:842946:;10106:spd:1000:in:3485258:out:1343591:;10107:spd:1000:in:3227714:out:1426624:;10108:spd:1000:in:1838642:out:868717:;10109:spd:1000:in:2487717:out:3209348:;10110:spd:100:in:1825124:out:885656:;10125:spd:1000:in:689169:out:3564177:;10126:spd:1000:in:1414928:out:3822096:;10127:spd:1000:in:1667769:out:3868716:;' 4506.231203609:main queue:Reg/w0: Message has legacy syslog format. 4506.231234104:main queue:Reg/w0: Filter: check for property 'programname' (value 'phb-nagios') isequal 'mac-notification': FALSE 4506.231262618:main queue:Reg/w0: Filter: check for property 'programname' (value 'phb-nagios') isequal 'phb-nagios': TRUE 4506.231290730:main queue:Reg/w0: Called action, logging to builtin-file 4506.231310290:main queue:Reg/w0: action 3 queue: entry added, size now 1 entries 4506.231335838:main queue:Reg/w0: wtpAdviseMaxWorkers signals busy 4506.231357815:main queue:Reg/w0: action 3 queue: EnqueueMsg advised worker start 4506.231393173:action 3 queue:Reg/w0: action 3 queue: entry deleted, state 0, size now 0 entries 4506.231424888:action 3 queue:Reg/w0: (/var/log/network-management/nagios3/from_syslog) 4506.231663271:action 3 queue:Reg/w0: action 3 queue:Reg/w0: worker IDLE, waiting for work. 4506.231705328:main queue:Reg/w0: Called action, logging to builtin-discard 4506.231726326:main queue:Reg/w0: 4506.231750193:main queue:Reg/w0: main queue:Reg/w0: worker IDLE, waiting for work. 4506.231776785:imtcp.c: main queue: EnqueueMsg advised worker start 4506.231814516:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4506.231860623:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4506.231880575:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4506.231900899:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4506.231921316:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4515.582324438:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4515.582380926:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4515.582401310:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4515.582420095:imtcp.c: GnuTLS requested retry of 2 operation - executing 4515.582439077:imtcp.c: retrying gtls recv, nsd: 0x9d38b70 4515.582468899:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4515.582489095:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 89 4515.582524035:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4515.582543648:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4515.582563150:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4515.582583688:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4515.582604546:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4515.582662040:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4515.582681988:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4515.582701278:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4515.582720259:imtcp.c: GnuTLS requested retry of 2 operation - executing 4515.582738823:imtcp.c: retrying gtls recv, nsd: 0x9d38b70 4515.582759301:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4515.582778969:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 89 4515.582802715:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4515.582822277:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4515.582841949:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4515.582861654:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4515.582881516:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 4515.582938534:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4515.582958097:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4515.582977554:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4515.582996240:imtcp.c: GnuTLS requested retry of 2 operation - executing 4515.583014998:imtcp.c: retrying gtls recv, nsd: 0x9d38b70 4515.583035223:imtcp.c: GnuTLS receive requires a retry (this most probably is OK and no error condition) 4515.583054935:imtcp.c: gtlsRecordRecv return. nsd 0x9d38b70, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 89 4515.583078036:imtcp.c: hasRcvInBuffer on nsd 0x9d38bf0: pszRcvBuf (nil), lenRcvBuf 0 4515.583097776:imtcp.c: hasRcvInBuffer on nsd 0x9d36260: pszRcvBuf (nil), lenRcvBuf 0 4515.583117306:imtcp.c: hasRcvInBuffer on nsd 0x9d38b70: pszRcvBuf 0x9d38f48, lenRcvBuf -1 4515.583137112:imtcp.c: hasRcvInBuffer on nsd 0x9d2f700: pszRcvBuf 0x9d3ef58, lenRcvBuf -1 4515.583156760:imtcp.c: --------<NSDSEL_PTCP> calling select, active fds (max 28): 25 26 27 28 HERE IS LINE 1428900 (1 428 900)
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Mon, 23 Nov 2009 10:06:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Marcin Szewczyk <Marcin.Szewczyk@wodny.org>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Mon, 23 Nov 2009 10:06:02 GMT) (full text, mbox, link).
Message #30 received at 549168@bugs.debian.org (full text, mbox, reply):
Some additional information. Previous configuration that fails after a couple of hours: rsyslog(internal SSL) ---- network ---> rsyslog(internal SSL) A one which works for a couple of days now: rsyslog(internal SSL) ---- network ---> stunnel4 --> rsyslog -- Marcin Szewczyk http://wodny.org mailto:Marcin.Szewczyk@wodny.borg <- remove b / usuń b xmpp:wodny@ubuntu.pl xmpp:wodny@jabster.pl
Changed Bug title to 'high memory usage when using TLS netstream driver' from 'rsyslog: consumes too much memory'
Request was from Michael Biebl <biebl@debian.org>
to control@bugs.debian.org.
(Wed, 24 Feb 2010 23:06:05 GMT) (full text, mbox, link).
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Sat, 04 Sep 2010 14:12:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Dererk <dererk@madap.com.ar>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Sat, 04 Sep 2010 14:12:03 GMT) (full text, mbox, link).
Message #37 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi. I'm experimenting the same issues, I'm almost sure the ram issues are a counterpart of the real hidden problem with the gnutls handshake process. Unfortunately the whole debug log is about 4G (no kidding), unless until it crashes, and the entries got repeated in a loop, in which I presume, the gnutls driver doesn't free any memory at all for the hasRcvInBuffer, which might result in the behaviour we see, until new date come up to the netstream socket and it starts all over again. This is an _extremely_ short chunk of debug trace I thought it might be relevant, first we see the normal behaviour, then the loop, and then what happens when new events come up into the netstream, and then looping again: 5133.153970956:402: main Q:Reg/w0: worker IDLE, waiting for work. 5133.165381396:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.165394796:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.165400356:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.165405596:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.165410796:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.165416236:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.165421636:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.165427156:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.165432836:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5133.165437716:1406: GnuTLS requested retry of 2 operation - executing 5133.165442436:1406: retrying gtls recv, nsd: 0x80e9338 5133.165539516:1406: gtlsRecordRecv return. nsd 0x80e9338, iRet 0, lenRcvd 106, lenRcvBuf 106, ptrRcvBuf 0 5133.165563076:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.165568636:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.165574036:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.165579196:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.165584356:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.165589796:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.165595076:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.165600276:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.165606156:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf 106 5133.165611916:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.165617556:1406: New connect on NSD 0x80d5aa0. 5133.165633836:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.165639036:1406: New connect on NSD 0x80e7ee8. 5133.165647356:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.165652596:1406: New connect on NSD 0x80e7c28. 5133.165660556:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.165665716:1406: New connect on NSD 0x80d4410. 5133.165673756:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.165683156:1406: New connect on NSD 0x80d4560. 5133.165691116:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.165696076:1406: New connect on NSD 0x80d3d90. 5133.165704076:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.165709396:1406: netstream 0x80d53c0 with new data 5133.165723636:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5133.165729516:1406: gtlsRecordRecv return. nsd 0x80d4c50, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 291 5133.165739116:1406: gtlsRcv return. nsd 0x80d4c50, iRet -2100, lenRcvBuf -1, ptrRcvBuf 291 5133.165744556:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.165749596:1406: netstream 0x80d5548 with new data 5133.165756036:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5133.165761796:1406: gtlsRecordRecv return. nsd 0x80e93e8, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 81 5133.165767356:1406: gtlsRcv return. nsd 0x80e93e8, iRet -2100, lenRcvBuf -1, ptrRcvBuf 81 5133.165772836:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf 106 5133.165777796:1406: netstream 0x80bcca0 with new data 5133.165783436:1406: gtlsRcv return. nsd 0x80e9338, iRet 0, lenRcvBuf -1, ptrRcvBuf 106 5133.165805956:1406: TCP Message with octet-counter, size 102. 5133.165816396:1406: queueMultiEnq: 0 5133.165823396:1406: main Q: entry added, size now 1 entries 5133.165830156:1406: wtpAdviseMaxWorkers signals busy 5133.165841956:1406: main Q: MultiEnqObj advised worker start 5133.165853236:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.165858756:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.165864076:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.165869316:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.165874956:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.165883836:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.165889156:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.165894636:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.165899876:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5133.165905516:1406: --------<NSDSEL_PTCP> calling select, active fds (max 26): 15 16 17 18 19 20 21 24 26 5133.165943476:402: main Q: entry deleted, state 0, size now 0 entries 5133.165952596:402: msg parser: flags 30, from 'customer-static.iplannetworks.net', msg '<22>Sep 4 09:58:49 foobar : liszt.debian.org (8) <=* 354 enter mail, end with "." on a line by itself' 5133.165957876:402: Message has legacy syslog format. 5133.165965556:402: testing filter, f_pmask 255 5133.165971156:402: Called action, logging to ommysql 5133.165987276:402: 5133.166217676:402: testing filter, f_pmask 0 5133.166234036:402: testing filter, f_pmask 0 5133.166239396:402: testing filter, f_pmask 0 5133.166244276:402: testing filter, f_pmask 0 5133.166249236:402: testing filter, f_pmask 0 5133.166254196:402: testing filter, f_pmask 255 5133.166260996:402: Called action, logging to builtin-file 5133.166275916:402: file to log to: /var/log/mail.log 5133.166281876:402: doWrite, pData->pStrm 0x80a4248, lenBuf 99 5133.166290396:402: strm 0x80a4248: file 27(mail.log) flush, buflen 99 5133.166309436:402: strm 0x80a4248: file 27 write wrote 99 bytes 5133.166357276:402: testing filter, f_pmask 0 5133.166363556:402: testing filter, f_pmask 127 5133.166369916:402: Called action, logging to builtin-file 5133.166382276:402: file to log to: /var/log/mail.info 5133.166387996:402: doWrite, pData->pStrm 0x80a5700, lenBuf 99 5133.166395356:402: strm 0x80a5700: file 28(mail.info) flush, buflen 99 5133.166408956:402: strm 0x80a5700: file 28 write wrote 99 bytes 5133.166416036:402: testing filter, f_pmask 31 5133.166420836:402: testing filter, f_pmask 15 5133.166425636:402: testing filter, f_pmask 0 5133.166430596:402: testing filter, f_pmask 0 5133.166435636:402: testing filter, f_pmask 0 5133.166440476:402: testing filter, f_pmask 0 5133.166445196:402: testing filter, f_pmask 0 5133.166455356:402: testing filter, f_pmask 1 5133.166460196:402: testing filter, f_pmask 255 5133.166467756:402: Called action, logging to builtin-pipe 5133.166475516:402: (/dev/xconsole) 5133.166484476:402: testing filter, f_pmask 0 5133.166491276:402: main Q:Reg/w0: worker IDLE, waiting for work. 5133.902546796:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.902560836:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.902566356:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.902571436:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.902576396:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.902581476:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.902587236:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.902591876:1406: GnuTLS requested retry of 2 operation - executing 5133.902596436:1406: retrying gtls recv, nsd: 0x80d4c50 5133.902610476:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5133.902616396:1406: gtlsRecordRecv return. nsd 0x80d4c50, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 291 5133.902637116:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.902642436:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.902647436:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.902652396:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.902657596:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.902662556:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.902667716:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.902673596:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.902678916:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5133.902684716:1406: --------<NSDSEL_PTCP> calling select, active fds (max 26): 15 16 17 18 19 20 21 24 26 5133.902710716:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.902716116:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.902721436:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.902726476:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.902731476:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.902741796:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.902747116:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.902751876:1406: GnuTLS requested retry of 2 operation - executing 5133.902756476:1406: retrying gtls recv, nsd: 0x80d4c50 5133.902762356:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5133.902768076:1406: gtlsRecordRecv return. nsd 0x80d4c50, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 291 5133.902776716:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.902781916:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.902786956:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.902792036:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.902797116:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.902802156:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.902807316:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.902812676:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.902817756:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5133.902822956:1406: --------<NSDSEL_PTCP> calling select, active fds (max 26): 15 16 17 18 19 20 21 24 26 5133.902901356:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.902907956:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.902913396:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.902918796:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.902924196:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.902934876:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.902940876:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.902945916:1406: GnuTLS requested retry of 2 operation - executing 5133.902956396:1406: retrying gtls recv, nsd: 0x80d4c50 5133.902971036:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5133.902977276:1406: gtlsRecordRecv return. nsd 0x80d4c50, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 291 5133.902998236:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.903007716:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.903013236:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.903018436:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.903023676:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.903029076:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.903034476:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.903040476:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5133.903046356:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5133.903052196:1406: --------<NSDSEL_PTCP> calling select, active fds (max 26): 15 16 17 18 19 20 21 24 26 5133.903075956:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5133.903114316:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5133.903119956:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5133.903125116:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5133.903130356:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5133.903135556:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5133.903140916:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5133.903145716:1406: GnuTLS requested retry of 2 operation - executing 5133.903150396:1406: retrying gtls recv, nsd: 0x80d4c50 5133.903158676:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) [LOOP of GnuTLS receive requires a retry, until....] 5134.166100516:1406: GnuTLS requested retry of 2 operation - executing 5134.166105316:1406: retrying gtls recv, nsd: 0x80e93e8 5134.166112796:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5134.166118756:1406: gtlsRecordRecv return. nsd 0x80e93e8, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 81 5134.166133716:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5134.166139396:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5134.166144596:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5134.166150076:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5134.166155276:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5134.166164076:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5134.166169676:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf 303 5134.166178316:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5134.166183916:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5134.166192796:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5134.166280676:1406: New connect on NSD 0x80d5aa0. 5134.166388116:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5134.166394116:1406: New connect on NSD 0x80e7ee8. 5134.166402116:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5134.166407036:1406: New connect on NSD 0x80e7c28. 5134.166467116:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5134.166472516:1406: New connect on NSD 0x80d4410. 5134.166480196:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5134.166485236:1406: New connect on NSD 0x80d4560. 5134.166492716:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5134.166497596:1406: New connect on NSD 0x80d3d90. 5134.166505276:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf 303 5134.166510676:1406: netstream 0x80d53c0 with new data 5134.166517236:1406: gtlsRcv return. nsd 0x80d4c50, iRet 0, lenRcvBuf -1, ptrRcvBuf 303 5134.166541796:1406: TCP Message with octet-counter, size 299. 5134.166554676:1406: queueMultiEnq: 0 5134.166562036:1406: main Q: entry added, size now 1 entries 5134.166569116:1406: wtpAdviseMaxWorkers signals busy 5134.166642316:402: main Q: entry deleted, state 0, size now 0 entries 5134.166713956:1406: main Q: MultiEnqObj advised worker start 5134.166766396:402: msg parser: flags 30, from 'reformating.please.wa.it', msg '<4>Sep 4 09:58:50 foobar kernel: [2335220.302190] [IPTABLES DROP] : unimportant log entry ' 5134.166775396:402: Message has legacy syslog format. 5134.166837556:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5134.166880756:402: testing filter, f_pmask 255 5134.166889356:402: Called action, logging to ommysql 5134.166907996:402: 5134.166940036:1406: GnuTLS requested retry of 2 operation - executing 5134.167062956:1406: retrying gtls recv, nsd: 0x80e93e8 5134.167134916:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) 5134.167203156:1406: gtlsRecordRecv return. nsd 0x80e93e8, iRet -2100, lenRcvd -28, lenRcvBuf -1, ptrRcvBuf 81 5134.167292916:402: testing filter, f_pmask 0 5134.167300396:402: testing filter, f_pmask 128 5134.167305356:402: testing filter, f_pmask 0 5134.167310276:402: testing filter, f_pmask 255 5134.167316236:402: Called action, logging to builtin-file 5134.167327716:402: file to log to: /var/log/kern.log 5134.167333476:402: doWrite, pData->pStrm 0x80a2d80, lenBuf 297 5134.167342236:402: strm 0x80a2d80: file 22(kern.log) flush, buflen 297 5134.167365436:402: strm 0x80a2d80: file 22 write wrote 297 bytes 5134.167374076:402: testing filter, f_pmask 0 5134.167379076:402: testing filter, f_pmask 0 5134.167384156:402: testing filter, f_pmask 0 5134.167388956:402: testing filter, f_pmask 0 5134.167393956:402: testing filter, f_pmask 0 5134.167398796:402: testing filter, f_pmask 0 5134.167403836:402: testing filter, f_pmask 0 5134.167408716:402: testing filter, f_pmask 0 5134.167413556:402: testing filter, f_pmask 0 5134.167418356:402: testing filter, f_pmask 128 5134.167423436:402: testing filter, f_pmask 112 5134.167428996:402: Called action, logging to builtin-file 5134.167436836:402: file to log to: /var/log/messages 5134.167442076:402: doWrite, pData->pStrm 0x80a9f88, lenBuf 297 5134.167447876:402: strm 0x80a9f88: file 14(messages) flush, buflen 297 5134.167459236:402: strm 0x80a9f88: file 14 write wrote 297 bytes 5134.167466036:402: testing filter, f_pmask 1 5134.167471356:402: testing filter, f_pmask 240 5134.167476916:402: Called action, logging to builtin-pipe 5134.167484476:402: (/dev/xconsole) 5134.167552876:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5134.167636756:402: pipe (6) write error 35: Resource temporarily unavailable 5134.167653636:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5134.167662556:402: Action requested to be suspended, done that. 5134.167669036:402: testing filter, f_pmask 112 5134.167677436:402: Called action, logging to builtin-file 5134.167685356:402: file to log to: /var/log/firewall/firewall.log 5134.167702156:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5134.167710116:402: doWrite, pData->pStrm 0x80ab2d8, lenBuf 297 5134.167716676:402: strm 0x80ab2d8: file 23(firewall.log) flush, buflen 297 5134.167736196:402: strm 0x80ab2d8: file 23 write wrote 297 bytes 5134.167746116:402: main Q:Reg/w0: worker IDLE, waiting for work. 5134.167761156:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5134.167766716:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5134.167771996:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5134.167777516:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5134.167783196:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5134.167788716:1406: hasRcvInBuffer on nsd 0x80e9338: pszRcvBuf 0x80fc6d8, lenRcvBuf -1 5134.167794916:1406: --------<NSDSEL_PTCP> calling select, active fds (max 26): 15 16 17 18 19 20 21 24 26 5134.167828556:1406: hasRcvInBuffer on nsd 0x80d4260: pszRcvBuf (nil), lenRcvBuf 0 5134.167834116:1406: hasRcvInBuffer on nsd 0x80d5908: pszRcvBuf (nil), lenRcvBuf 0 5134.167839556:1406: hasRcvInBuffer on nsd 0x80e7f50: pszRcvBuf (nil), lenRcvBuf 0 5134.167844796:1406: hasRcvInBuffer on nsd 0x80e7c90: pszRcvBuf (nil), lenRcvBuf 0 5134.167849996:1406: hasRcvInBuffer on nsd 0x80d4478: pszRcvBuf (nil), lenRcvBuf 0 5134.167855436:1406: hasRcvInBuffer on nsd 0x80d45c8: pszRcvBuf (nil), lenRcvBuf 0 5134.167860756:1406: hasRcvInBuffer on nsd 0x80d4c50: pszRcvBuf 0x80ed5a0, lenRcvBuf -1 5134.167866076:1406: hasRcvInBuffer on nsd 0x80e93e8: pszRcvBuf 0x80f35b0, lenRcvBuf -1 5134.167925196:1406: GnuTLS requested retry of 2 operation - executing 5134.167992556:1406: retrying gtls recv, nsd: 0x80e93e8 5134.168010636:1406: GnuTLS receive requires a retry (this most probably is OK and no error condition) Then the whole story starts all over and over again. Just a side note, I'm running several TLS clients, all of them going to different InputTCPServerRun ports, all of them are using 4.6.4-1 version, server is running of mysql and gnutls drivers over kfreebsd-i386 this time, but I suffer from this behaviour in exactly the same way as I did on i386 port. My rsyslog.conf is completely standard and my tls.conf at rsyslog.d/ is this (from rsyslog docs): # make gtls driver the default $DefaultNetstreamDriver gtls # certificate files $DefaultNetstreamDriverCAFile /usr/share/ca-certificates/cacert.org/cacert.org.crt $DefaultNetstreamDriverCertFile /path/server.cert $DefaultNetstreamDriverKeyFile /path/private.key $ModLoad imtcp # load TCP listener $InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode $InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated $InputTCPServerRun 10514 $InputTCPServerRun 10515 $InputTCPServerRun 10516 Clients have exactly this very same config (except of the different port, of course :) ) # certificate files - just CA for a client $DefaultNetstreamDriverCAFile /path/ca.pem # set up the action $DefaultNetstreamDriver gtls # use gtls netstream driver $ActionSendStreamDriverMode 1 # require TLS for the connection $ActionSendStreamDriverAuthMode anon # server is NOT authenticated *.* @@(o)IP:PORT # send (all) messages Please ask me for any possible information or process you may need, thanks in advance! Greetings, Dererk -- BOFH excuse #405: Sysadmins unavailable because they are in a meeting talking about why they are unavailable so much.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Fri, 05 Nov 2010 21:57:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Plamen Tonev <plamen@tonev.net>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Fri, 05 Nov 2010 21:57:06 GMT) (full text, mbox, link).
Message #42 received at 549168@bugs.debian.org (full text, mbox, reply):
I'm experiencing the same problem. The rsyslogd with gnutls enabled and 1-2 minutes after start it is starting to use 100% CPU usage - until killed. It is some sort of infinite loop...the debug file is REALLY big....and obviously something is broken with rsyslog+gnutls. I was thinking that it was some RBAC restrtiction with my grsec kernel, but I have compiled clean vanilla 2.6.36 kernel - and surprisingly - it takes 100% CPU even without grsecurity restrictions. Best regards, Plamen Tonev
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Tue, 09 Nov 2010 11:39:08 GMT) (full text, mbox, link).
Acknowledgement sent
to "Rainer Gerhards" <rgerhards@hq.adiscon.com>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Tue, 09 Nov 2010 11:39:08 GMT) (full text, mbox, link).
Message #47 received at 549168@bugs.debian.org (full text, mbox, reply):
> -----Original Message----- > From: Plamen Tonev [mailto:plamen@tonev.net] > Sent: Friday, November 05, 2010 10:45 PM > To: 549168@bugs.debian.org > Subject: Bug#549168: rsyslog: consumes too much memory > > I'm experiencing the same problem. The rsyslogd with gnutls enabled and > 1-2 minutes after start it is starting to use 100% CPU usage - until > killed. It is some sort of infinite loop...the debug file is REALLY > big....and obviously > something is broken with rsyslog+gnutls. > I was thinking that it was some RBAC restrtiction with my grsec kernel, > but I have compiled clean vanilla 2.6.36 kernel - and surprisingly - it > takes 100% CPU even without grsecurity restrictions. I am the rsyslog author. I just came across this very useful Debian bug report. I am tracking this issue for some while now in rsyslog's bugzilla under http://bugzilla.adiscon.com/show_bug.cgi?id=194 A big problem is that I seem to be unable to reproduce the issue (but I will retry with the configs posted here, however, the look extremely similar to what I already use). Question now: would those of you who can reproduce it be willing to test a special version that I modify so that it contains some more instrumentation? From what I have seen so far, it looks that for some reason GnuTLS requires an operaton retry (something absolutely OK with TLS) but then seems to be unable to finish it. That leads to a retry loop. But I have very little insight into the situation and so any help is deeply appreciated. Thanks, Rainer
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Mon, 29 Nov 2010 21:30:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Dererk <dererk@debian.org>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Mon, 29 Nov 2010 21:30:03 GMT) (full text, mbox, link).
Message #52 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On -10/01/37 16:59, Rainer Gerhards wrote: >> -----Original Message----- >> From: Plamen Tonev [mailto:plamen@tonev.net] >> Sent: Friday, November 05, 2010 10:45 PM >> To: 549168@bugs.debian.org >> Subject: Bug#549168: rsyslog: consumes too much memory >> >> I'm experiencing the same problem. The rsyslogd with gnutls enabled and >> 1-2 minutes after start it is starting to use 100% CPU usage - until >> killed. It is some sort of infinite loop...the debug file is REALLY >> big....and obviously >> something is broken with rsyslog+gnutls. >> I was thinking that it was some RBAC restrtiction with my grsec kernel, >> but I have compiled clean vanilla 2.6.36 kernel - and surprisingly - it >> takes 100% CPU even without grsecurity restrictions. >> > I am the rsyslog author. I just came across this very useful Debian bug > report. I am tracking this issue for some while now in rsyslog's bugzilla > under > > http://bugzilla.adiscon.com/show_bug.cgi?id=194 > > A big problem is that I seem to be unable to reproduce the issue (but I will > retry with the configs posted here, however, the look extremely similar to > what I already use). > > Question now: would those of you who can reproduce it be willing to test a > special version that I modify so that it contains some more instrumentation? > > >From what I have seen so far, it looks that for some reason GnuTLS requires > an operaton retry (something absolutely OK with TLS) but then seems to be > unable to finish it. That leads to a retry loop. But I have very little > insight into the situation and so any help is deeply appreciated. > > Thanks, > Rainer > Hi Rainer, pleased to meet you and thanks for replying on this thread :-) I can offer myself with a demo environment whenever you need it, although I must say It's really pretty straight forward to reproduce, I came across the same issue in two different times and completely different environments. Just for the sake of any random sailor to arrive at this lands, It would be much helpful if you don't mind dropping the steps/links required for you to debug. Please do let me know if you need anything else I could provide you with. Cheers, Dererk -- BOFH excuse #306: CPU-angle has to be adjusted because of vibrations coming from the nearby road
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Tue, 30 Nov 2010 10:03:02 GMT) (full text, mbox, link).
Acknowledgement sent
to "Rainer Gerhards" <rgerhards@hq.adiscon.com>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Tue, 30 Nov 2010 10:03:02 GMT) (full text, mbox, link).
Message #57 received at 549168@bugs.debian.org (full text, mbox, reply):
Hi Derek, have a look at our upstream bug tracker -- the issue finally got solved :) New releases are being rolled out. http://bugzilla.adiscon.com/show_bug.cgi?id=194 Rainer > -----Original Message----- > From: Dererk [mailto:dererk@debian.org] > Sent: Monday, November 29, 2010 10:27 PM > To: Rainer Gerhards > Cc: Plamen Tonev; 549168@bugs.debian.org > Subject: Bug#549168: RE: Bug#549168: rsyslog: consumes too much memory > > On -10/01/37 16:59, Rainer Gerhards wrote: > >> -----Original Message----- > >> From: Plamen Tonev [mailto:plamen@tonev.net] > >> Sent: Friday, November 05, 2010 10:45 PM > >> To: 549168@bugs.debian.org > >> Subject: Bug#549168: rsyslog: consumes too much memory > >> > >> I'm experiencing the same problem. The rsyslogd with gnutls enabled > and > >> 1-2 minutes after start it is starting to use 100% CPU usage - until > >> killed. It is some sort of infinite loop...the debug file is REALLY > >> big....and obviously > >> something is broken with rsyslog+gnutls. > >> I was thinking that it was some RBAC restrtiction with my grsec > kernel, > >> but I have compiled clean vanilla 2.6.36 kernel - and surprisingly - > it > >> takes 100% CPU even without grsecurity restrictions. > >> > > I am the rsyslog author. I just came across this very useful Debian > bug > > report. I am tracking this issue for some while now in rsyslog's > bugzilla > > under > > > > http://bugzilla.adiscon.com/show_bug.cgi?id=194 > > > > A big problem is that I seem to be unable to reproduce the issue (but > I will > > retry with the configs posted here, however, the look extremely > similar to > > what I already use). > > > > Question now: would those of you who can reproduce it be willing to > test a > > special version that I modify so that it contains some more > instrumentation? > > > > >From what I have seen so far, it looks that for some reason GnuTLS > requires > > an operaton retry (something absolutely OK with TLS) but then seems > to be > > unable to finish it. That leads to a retry loop. But I have very > little > > insight into the situation and so any help is deeply appreciated. > > > > Thanks, > > Rainer > > > Hi Rainer, pleased to meet you and thanks for replying on this thread > :-) > > I can offer myself with a demo environment whenever you need it, > although I must say It's really pretty straight forward to reproduce, I > came across the same issue in two different times and completely > different environments. > > Just for the sake of any random sailor to arrive at this lands, It > would > be much helpful if you don't mind dropping the steps/links required for > you to debug. > > > Please do let me know if you need anything else I could provide you > with. > > > Cheers, > > Dererk > > -- > BOFH excuse #306: > CPU-angle has to be adjusted because of vibrations coming from the > nearby road >
Reply sent
to Michael Biebl <biebl@debian.org>:
You have taken responsibility.
(Tue, 30 Nov 2010 14:33:08 GMT) (full text, mbox, link).
Notification sent
to Christoph Martin <martin@uni-mainz.de>:
Bug acknowledged by developer.
(Tue, 30 Nov 2010 14:33:08 GMT) (full text, mbox, link).
Message #62 received at 549168-close@bugs.debian.org (full text, mbox, reply):
Source: rsyslog
Source-Version: 4.6.4-2
We believe that the bug you reported is fixed in the latest version of
rsyslog, which is due to be installed in the Debian FTP archive:
rsyslog-doc_4.6.4-2_all.deb
to main/r/rsyslog/rsyslog-doc_4.6.4-2_all.deb
rsyslog-gnutls_4.6.4-2_i386.deb
to main/r/rsyslog/rsyslog-gnutls_4.6.4-2_i386.deb
rsyslog-gssapi_4.6.4-2_i386.deb
to main/r/rsyslog/rsyslog-gssapi_4.6.4-2_i386.deb
rsyslog-mysql_4.6.4-2_i386.deb
to main/r/rsyslog/rsyslog-mysql_4.6.4-2_i386.deb
rsyslog-pgsql_4.6.4-2_i386.deb
to main/r/rsyslog/rsyslog-pgsql_4.6.4-2_i386.deb
rsyslog-relp_4.6.4-2_i386.deb
to main/r/rsyslog/rsyslog-relp_4.6.4-2_i386.deb
rsyslog_4.6.4-2.debian.tar.gz
to main/r/rsyslog/rsyslog_4.6.4-2.debian.tar.gz
rsyslog_4.6.4-2.dsc
to main/r/rsyslog/rsyslog_4.6.4-2.dsc
rsyslog_4.6.4-2_i386.deb
to main/r/rsyslog/rsyslog_4.6.4-2_i386.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 549168@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Biebl <biebl@debian.org> (supplier of updated rsyslog package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Tue, 30 Nov 2010 14:50:15 +0100
Source: rsyslog
Binary: rsyslog rsyslog-doc rsyslog-mysql rsyslog-pgsql rsyslog-gssapi rsyslog-gnutls rsyslog-relp
Architecture: source i386 all
Version: 4.6.4-2
Distribution: unstable
Urgency: low
Maintainer: Michael Biebl <biebl@debian.org>
Changed-By: Michael Biebl <biebl@debian.org>
Description:
rsyslog - enhanced multi-threaded syslogd
rsyslog-doc - documentation for rsyslog
rsyslog-gnutls - TLS protocol support for rsyslog
rsyslog-gssapi - GSSAPI authentication and encryption support for rsyslog
rsyslog-mysql - MySQL output plugin for rsyslog
rsyslog-pgsql - PostgreSQL output plugin for rsyslog
rsyslog-relp - RELP protocol support for rsyslog
Closes: 549168
Changes:
rsyslog (4.6.4-2) unstable; urgency=low
.
* debian/patches/02-tls_loop_fix.patch
- Fix bug in TLS handling which could cause rsyslog to loop in a tight
loop and eating up all CPU and RAM resources. Closes: #549168
Patch cherry-picked from upstream Git.
Checksums-Sha1:
846ba2c2b3dd996161d2d45a7fdc443afb16d305 2000 rsyslog_4.6.4-2.dsc
349b5fb2c0be07506dbefe86e453c70a4f2bfc47 24248 rsyslog_4.6.4-2.debian.tar.gz
99ae53c87ca9707d1480cc0153744052dda51d3b 308246 rsyslog_4.6.4-2_i386.deb
d9642ff32e04dbcb405d42fb5abbebfa05feec22 1031676 rsyslog-doc_4.6.4-2_all.deb
051b134d57129e750b26a67072e725a02146885a 99106 rsyslog-mysql_4.6.4-2_i386.deb
9650baeab325920b77d4e346a4d4bc51b4517eea 98946 rsyslog-pgsql_4.6.4-2_i386.deb
86a62588ea2896d367397d5bd43075b4ff547aa7 106242 rsyslog-gssapi_4.6.4-2_i386.deb
d9631f56c36e05a0ee496ec34804237c65c514d1 105660 rsyslog-gnutls_4.6.4-2_i386.deb
d1095954eb4921e52ac4da0e9f90b04484960b5e 99338 rsyslog-relp_4.6.4-2_i386.deb
Checksums-Sha256:
636c394c1c4d2ff74a4981ff8d3ac7e75e10f073411b0e4f578e0208cbdeb1d7 2000 rsyslog_4.6.4-2.dsc
9ed6639508b6003856dea6ebf4247a3fe8fa1f2f166f9ab6c9d12db17f07b863 24248 rsyslog_4.6.4-2.debian.tar.gz
a0c606452eccd924d709cec67c6b935e3ad486c7e4ee978ab3aa33b422195206 308246 rsyslog_4.6.4-2_i386.deb
4f4c04235f797845af5b40c18d76c98bd2d264abaf0a3c77b347770c2c2fd27d 1031676 rsyslog-doc_4.6.4-2_all.deb
5b1741941acf32826d3cc38b4c4cdcd0b5cf11132349ad5644eb3bb997076886 99106 rsyslog-mysql_4.6.4-2_i386.deb
8ca82e958b507a6ff32f729ea48966f25d62d83b6d458fd2a3a90f8224300bfa 98946 rsyslog-pgsql_4.6.4-2_i386.deb
0e66e9705ccbb8b8546f2332ebd542dd4004eaf623672727a01b6b9f89add036 106242 rsyslog-gssapi_4.6.4-2_i386.deb
74aa99314be401648b845bd246ec0a6b6b1d38d621b73458b0d2fcae6914f05f 105660 rsyslog-gnutls_4.6.4-2_i386.deb
aff3bd9c03484a8a29c4b9d825c73bad26e66c37546760f7a172ab088353ea8e 99338 rsyslog-relp_4.6.4-2_i386.deb
Files:
298d5184ad291d046e795c1925d0a230 2000 admin important rsyslog_4.6.4-2.dsc
156def9ea4fd7a75c92e0c9f80b53657 24248 admin important rsyslog_4.6.4-2.debian.tar.gz
71e4cef4a1a4d85b9348f208d54b7520 308246 admin important rsyslog_4.6.4-2_i386.deb
1701c2c57dcb2e482256ae934ceeb4ab 1031676 doc extra rsyslog-doc_4.6.4-2_all.deb
dfcd7999f06b60449078b4f802a4710a 99106 admin extra rsyslog-mysql_4.6.4-2_i386.deb
0c4ad35bdd07c999bfb5b57f7c2650a8 98946 admin extra rsyslog-pgsql_4.6.4-2_i386.deb
e05dbade7912972d65f9e250f11d708b 106242 admin extra rsyslog-gssapi_4.6.4-2_i386.deb
27260b2f11e2022cfe67d86a17dd11f1 105660 admin extra rsyslog-gnutls_4.6.4-2_i386.deb
039e736edb085547e0c46244ba2cfca7 99338 admin extra rsyslog-relp_4.6.4-2_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJM9QQlAAoJEGrh3w1gjyLc5KsP/AxAuKVhzTpLesL5+obX0bZE
i4rm5Lbslzx1GzWnShzWw/ny1QbDhln/l3YoUlGPttjWm2P5X8vEIiks8786G+Qh
djuK3sKrl+8m3XdMp/OsejmGpkBxmATAhpX6tdlJYgqREk+Ae5k8CAWvwn0OX9uW
pQ6r0+oKhNh4GzVW+tZ3PjJ7km0twBkRYsFvbgpXSRqiba2LqyShuztJVwDqihOZ
WQfQFPRygFBzT516GQQWLmpK7cjjJOyCH95Z5Veav7y1TJjluOMK3K1zMFR1k432
XBjYKzlz26dXgN2T2jyjtzTuyHvYDHxvs4PXiL9DN965MJ9ZXo8gubEiMWnc8KaK
w160Qi1dviVGdmWBJGmKkScQHIBN4oOO0tXrvs9rLggxgjQ1pHibmK6Aie0sQv5g
6Q/1PfcXKgOZ1v+sw6NSyZ5zmWrnwyGwetFgBJFtBy2J1Vy8P4ZRHpxTHAPgyGTe
5BFYHv/39rJ9MgYn26oh1phjscNRmegNC8IShip7uUnNxIltXZA1xvCC0QkoHgY3
XJ7I/txvfrcYHimvw0jWhYNyiyxgYErz1kR31nvKCzQgO6n0XHNHvvly03EqwlQs
N+lwdXRbmcLcHccPvHNuXS8zPR1srScxYSQo4p3dN+hyApW6A/j1fjtijp6B8P59
oxUVSdQcVKD6yFOFoWzO
=r+MC
-----END PGP SIGNATURE-----
Information forwarded
to debian-bugs-dist@lists.debian.org:
Bug#549168; Package rsyslog.
(Tue, 30 Nov 2010 14:39:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list.
(Tue, 30 Nov 2010 14:39:06 GMT) (full text, mbox, link).
Message #67 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 01.10.2009 08:31, Christoph Martin wrote: > I use the syslog-tls feature to send syslog messages from a bunch of host > to a centralized rsyslog server. On initial startup of rsyslog on > the syslog server it consumes allready about 170M. If I only have one > client which sends syslog messages it stays like this. But when I > start the syslogs senders on one to three other host, the memory > quickly (in minutes) goes up to 2G. The machine then goes in to > swapping and is mostly unusable. Hi everyone, I cherry-picked the fix from upstream Git and uploaded it as 4.6.4-2. Please test this version and let me know if that fixes your problem. I'll then ask for a freeze-exception, so this fix get's into squeeze. Thanks, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Wed, 01 Dec 2010 12:57:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Christoph Martin <martin@uni-mainz.de>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Wed, 01 Dec 2010 12:57:03 GMT) (full text, mbox, link).
Message #72 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Michael, Am 30.11.2010 15:38, schrieb Michael Biebl: > On 01.10.2009 08:31, Christoph Martin wrote: >> I use the syslog-tls feature to send syslog messages from a bunch of host >> to a centralized rsyslog server. On initial startup of rsyslog on >> the syslog server it consumes allready about 170M. If I only have one >> client which sends syslog messages it stays like this. But when I >> start the syslogs senders on one to three other host, the memory >> quickly (in minutes) goes up to 2G. The machine then goes in to >> swapping and is mostly unusable. > > Hi everyone, > > I cherry-picked the fix from upstream Git and uploaded it as 4.6.4-2. > > Please test this version and let me know if that fixes your problem. > > I'll then ask for a freeze-exception, so this fix get's into squeeze. I exchanged the rsyslog receiver now with the unstable version and it did not grow in the last two hours. So this looks fine for me. Christoph -- ============================================================================ Christoph Martin, Zentrum für Datenverarbeitung, Uni-Mainz, Germany Instant-Messaging: Jabber: martin@uni-mainz.de (Siehe http://www.zdv.uni-mainz.de/4010.php)
[martin.vcf (text/x-vcard, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Wed, 01 Dec 2010 17:42:06 GMT) (full text, mbox, link).
Acknowledgement sent
to Dererk <dererk@debian.org>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Wed, 01 Dec 2010 17:42:06 GMT) (full text, mbox, link).
Message #77 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 30/11/10 11:38, Michael Biebl wrote: > On 01.10.2009 08:31, Christoph Martin wrote: > >> I use the syslog-tls feature to send syslog messages from a bunch of host >> to a centralized rsyslog server. On initial startup of rsyslog on >> the syslog server it consumes allready about 170M. If I only have one >> client which sends syslog messages it stays like this. But when I >> start the syslogs senders on one to three other host, the memory >> quickly (in minutes) goes up to 2G. The machine then goes in to >> swapping and is mostly unusable. >> > Hi everyone, > > I cherry-picked the fix from upstream Git and uploaded it as 4.6.4-2. > > Please test this version and let me know if that fixes your problem. > > I'll then ask for a freeze-exception, so this fix get's into squeeze. > > Thanks, > Michael > Thanks Michael! It appears so far to be working fine. It's around 4 hours now and I've not seen any behaviour the older version uses to do in just 20 minutes. Thanks! :-) Cheers, Dererk -- BOFH excuse #306: CPU-angle has to be adjusted because of vibrations coming from the nearby road
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to debian-bugs-dist@lists.debian.org, Michael Biebl <biebl@debian.org>:
Bug#549168; Package rsyslog.
(Thu, 02 Dec 2010 13:27:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Christoph Martin <martin@uni-mainz.de>:
Extra info received and forwarded to list. Copy sent to Michael Biebl <biebl@debian.org>.
(Thu, 02 Dec 2010 13:27:03 GMT) (full text, mbox, link).
Message #82 received at 549168@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Am 30.11.2010 15:38, schrieb Michael Biebl: > On 01.10.2009 08:31, Christoph Martin wrote: >> I use the syslog-tls feature to send syslog messages from a bunch of host >> to a centralized rsyslog server. On initial startup of rsyslog on >> the syslog server it consumes allready about 170M. If I only have one >> client which sends syslog messages it stays like this. But when I >> start the syslogs senders on one to three other host, the memory >> quickly (in minutes) goes up to 2G. The machine then goes in to >> swapping and is mostly unusable. > > Hi everyone, > > I cherry-picked the fix from upstream Git and uploaded it as 4.6.4-2. > > Please test this version and let me know if that fixes your problem. > > I'll then ask for a freeze-exception, so this fix get's into squeeze. rsyslog server is now running for a day with 148m of memory. Christoph -- ============================================================================ Christoph Martin, Zentrum für Datenverarbeitung, Uni-Mainz, Germany Instant-Messaging: Jabber: martin@uni-mainz.de (Siehe http://www.zdv.uni-mainz.de/4010.php)
[martin.vcf (text/x-vcard, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Set Bug forwarded-to-address to 'http://bugzilla.adiscon.com/show_bug.cgi?id=194'.
Request was from Michael Biebl <biebl@debian.org>
to control@bugs.debian.org.
(Wed, 15 Dec 2010 15:33:10 GMT) (full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Thu, 13 Jan 2011 07:33:32 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.