Activity log for bug #1655153

Date Who What changed Old value New value Message
2017-01-09 21:28:19 Bruce Guenter bug added bug
2017-01-25 00:27:28 Launchpad Janitor stunnel4 (Ubuntu): status New Confirmed
2017-01-26 23:30:16 Scott Emmons bug added subscriber scotte
2017-01-27 23:28:03 Alberto Salvia Novella stunnel4 (Ubuntu): importance Undecided Medium
2017-01-27 23:28:39 Alberto Salvia Novella stunnel4 (Ubuntu): importance Medium High
2017-01-27 23:29:02 Alberto Salvia Novella stunnel4 (Ubuntu): importance High Medium
2017-06-07 17:58:57 Scott Emmons attachment added stunnel4_5.30-1.1.debdiff https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1655153/+attachment/4891557/+files/stunnel4_5.30-1.1.debdiff
2017-06-07 20:24:19 Ubuntu Foundations Team Bug Bot tags apport-bug i386 xenial apport-bug i386 patch xenial
2017-06-07 20:24:28 Ubuntu Foundations Team Bug Bot bug added subscriber Ubuntu Sponsors Team
2017-06-07 21:30:00 Scott Emmons bug watch added http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864391
2017-06-07 22:32:46 Brian Murray bug task added stunnel4 (Debian)
2017-06-08 22:55:26 Bug Watch Updater stunnel4 (Debian): status Unknown New
2017-06-28 21:48:28 Bug Watch Updater stunnel4 (Debian): status New Fix Released
2017-08-22 14:48:47 Bryan Quigley nominated for series Ubuntu Xenial
2017-08-22 14:49:49 Bryan Quigley bug added subscriber Bryan Quigley
2017-08-30 10:15:34 Simon Quigley bug task added stunnel4 (Ubuntu Xenial)
2017-08-30 10:15:46 Simon Quigley stunnel4 (Ubuntu Xenial): status New Fix Released
2017-08-30 10:17:56 Simon Quigley stunnel4 (Ubuntu Xenial): status Fix Released Confirmed
2017-08-30 10:18:01 Simon Quigley stunnel4 (Ubuntu): status Confirmed Fix Released
2017-08-30 10:18:13 Simon Quigley stunnel4 (Ubuntu Xenial): importance Undecided Medium
2017-08-30 10:33:45 Simon Quigley removed subscriber Ubuntu Sponsors Team
2017-08-31 15:55:57 Scott Emmons attachment added stunnel4_5.30-1ubuntu0.1.debdiff https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1655153/+attachment/4941892/+files/stunnel4_5.30-1ubuntu0.1.debdiff
2017-08-31 15:56:31 Scott Emmons attachment removed stunnel4_5.30-1.1.debdiff https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1655153/+attachment/4891557/+files/stunnel4_5.30-1.1.debdiff
2017-08-31 23:27:31 Scott Emmons description We are running a long-running stunnel4 daemon to proxy TLS connections to another set of servers. After leaving it running for a few weeks, its memory usage had grown to 1.5GB. Restarting it reduced its memory usage to expected levels (VSZ and RSS) but while I've been watching it today it has grown by more than 10MB. The stunnel website indicates that there have been fixes relating to memory leaks in versions 5.32 and 5.33, but Ubuntu LTS is still running 5.30. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: stunnel4 3:5.30-1 ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21 Uname: Linux 4.4.0-45-generic i686 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: i386 Date: Mon Jan 9 16:03:37 2017 InstallationDate: Installed on 2015-10-31 (435 days ago) InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release i386 (20151021) ProcEnviron: TERM=xterm SHELL=/bin/bash PATH=(custom, no user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR=<set> SourcePackage: stunnel4 UpgradeStatus: Upgraded to xenial on 2016-05-18 (236 days ago) mtime.conffile..etc.default.stunnel4: 2016-10-26T22:22:28.166247 We are running a long-running stunnel4 daemon to proxy TLS connections to another set of servers. After leaving it running for a few weeks, its memory usage had grown to 1.5GB. Restarting it reduced its memory usage to expected levels (VSZ and RSS) but while I've been watching it today it has grown by more than 10MB. The stunnel website indicates that there have been fixes relating to memory leaks in versions 5.32 and 5.33, but Ubuntu LTS is still running 5.30. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: stunnel4 3:5.30-1 ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21 Uname: Linux 4.4.0-45-generic i686 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: i386 Date: Mon Jan 9 16:03:37 2017 InstallationDate: Installed on 2015-10-31 (435 days ago) InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release i386 (20151021) ProcEnviron:  TERM=xterm  SHELL=/bin/bash  PATH=(custom, no user)  LANG=en_US.UTF-8  XDG_RUNTIME_DIR=<set> SourcePackage: stunnel4 UpgradeStatus: Upgraded to xenial on 2016-05-18 (236 days ago) mtime.conffile..etc.default.stunnel4: 2016-10-26T22:22:28.166247 === [Impact] * This bug results in a leak of TLS session objects in the stunnel4 server whenever a connection is closed. For a long running stunnel4 server, it can eventually consume all available memory. * This bug was introduced in stunnel 5.27, and subsequently fixed in 5.33. Ubuntu Xenial uses 5.30. * For Ubuntu, only Xenial is currently impacted by this bug, as previous versions of Ubuntu use an older version of stunnel4 (prior to 5.27), and later versions of Ubuntu use a newer version of stunnel4 (at least 5.33). * This patch backports a single specific fix to free TLS session objects when a connection is closed, but contains no other changes from newer stunnel4 versions. [Test Case] * The bug and fix can be reproduced fairly easily by setting up an stunnel4 server, then using openssl s_client to hammer against the stunnel4 server. For example, with the server running on localhost port 443, proxying to a local Apache instance, and using a client certificate: = #!/bin/bash while true; do echo "" | openssl s_client -connect localhost:443 \ -cert /etc/stunnel/client.pem done = In another window, monitor RSS of the stunnel4 server process with something like: = watch 'ps -p $(</var/run/stunnel4/pid) -o rss,comm' = * The RSS of the stunnel4 process will continue to grow over time. * After installing the patched version via my PPA[1] and re-running the test, the RSS of the stunnel4 process will grow for a few minutes and then reach a steady state where it no longer continues to grow. [1] https://launchpad.net/~lscotte/+archive/ubuntu/stunnel4 [Regression Potential] * None expected. This backports a fix in newer versions of upstream stunnel4. * In my own environment, I've been running a production stunnel4 server with my patch for over 85 days (zero restarts of the stunnel4 process). With the current Xenial version I was unable to run for more than 1 day without restarting stunnel4.
2017-08-31 23:28:27 Scott Emmons bug added subscriber Ubuntu Sponsors Team
2017-09-01 05:51:35 Simon Quigley description We are running a long-running stunnel4 daemon to proxy TLS connections to another set of servers. After leaving it running for a few weeks, its memory usage had grown to 1.5GB. Restarting it reduced its memory usage to expected levels (VSZ and RSS) but while I've been watching it today it has grown by more than 10MB. The stunnel website indicates that there have been fixes relating to memory leaks in versions 5.32 and 5.33, but Ubuntu LTS is still running 5.30. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: stunnel4 3:5.30-1 ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21 Uname: Linux 4.4.0-45-generic i686 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: i386 Date: Mon Jan 9 16:03:37 2017 InstallationDate: Installed on 2015-10-31 (435 days ago) InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release i386 (20151021) ProcEnviron:  TERM=xterm  SHELL=/bin/bash  PATH=(custom, no user)  LANG=en_US.UTF-8  XDG_RUNTIME_DIR=<set> SourcePackage: stunnel4 UpgradeStatus: Upgraded to xenial on 2016-05-18 (236 days ago) mtime.conffile..etc.default.stunnel4: 2016-10-26T22:22:28.166247 === [Impact] * This bug results in a leak of TLS session objects in the stunnel4 server whenever a connection is closed. For a long running stunnel4 server, it can eventually consume all available memory. * This bug was introduced in stunnel 5.27, and subsequently fixed in 5.33. Ubuntu Xenial uses 5.30. * For Ubuntu, only Xenial is currently impacted by this bug, as previous versions of Ubuntu use an older version of stunnel4 (prior to 5.27), and later versions of Ubuntu use a newer version of stunnel4 (at least 5.33). * This patch backports a single specific fix to free TLS session objects when a connection is closed, but contains no other changes from newer stunnel4 versions. [Test Case] * The bug and fix can be reproduced fairly easily by setting up an stunnel4 server, then using openssl s_client to hammer against the stunnel4 server. For example, with the server running on localhost port 443, proxying to a local Apache instance, and using a client certificate: = #!/bin/bash while true; do echo "" | openssl s_client -connect localhost:443 \ -cert /etc/stunnel/client.pem done = In another window, monitor RSS of the stunnel4 server process with something like: = watch 'ps -p $(</var/run/stunnel4/pid) -o rss,comm' = * The RSS of the stunnel4 process will continue to grow over time. * After installing the patched version via my PPA[1] and re-running the test, the RSS of the stunnel4 process will grow for a few minutes and then reach a steady state where it no longer continues to grow. [1] https://launchpad.net/~lscotte/+archive/ubuntu/stunnel4 [Regression Potential] * None expected. This backports a fix in newer versions of upstream stunnel4. * In my own environment, I've been running a production stunnel4 server with my patch for over 85 days (zero restarts of the stunnel4 process). With the current Xenial version I was unable to run for more than 1 day without restarting stunnel4. [Impact]  * This bug results in a leak of TLS session objects in the stunnel4 server whenever a connection is closed. For a long running stunnel4 server, it can eventually consume all available memory.  * This bug was introduced in stunnel 5.27, and subsequently fixed in 5.33. Ubuntu Xenial uses 5.30.  * For Ubuntu, only Xenial is currently impacted by this bug, as previous versions of Ubuntu use an older version of stunnel4 (prior to 5.27), and later versions of Ubuntu use a newer version of stunnel4 (at least 5.33).  * This patch backports a single specific fix to free TLS session objects when a connection is closed, but contains no other changes from newer stunnel4 versions. [Test Case]  * The bug and fix can be reproduced fairly easily by setting up an stunnel4 server, then using openssl s_client to hammer against the stunnel4 server. For example, with the server running on localhost port 443, proxying to a local Apache instance, and using a client certificate: = #!/bin/bash while true; do   echo "" | openssl s_client -connect localhost:443 \     -cert /etc/stunnel/client.pem done = In another window, monitor RSS of the stunnel4 server process with something like: = watch 'ps -p $(</var/run/stunnel4/pid) -o rss,comm' =  * The RSS of the stunnel4 process will continue to grow over time.  * After installing the patched version via my PPA[1] and re-running the test, the RSS of the stunnel4 process will grow for a few minutes and then reach a steady state where it no longer continues to grow. [1] https://launchpad.net/~lscotte/+archive/ubuntu/stunnel4 [Regression Potential]  * None expected. This backports a fix in newer versions of upstream stunnel4.  * In my own environment, I've been running a production stunnel4 server with my patch for over 85 days (zero restarts of the stunnel4 process). With the current Xenial version I was unable to run for more than 1 day without restarting stunnel4. [Original Description] We are running a long-running stunnel4 daemon to proxy TLS connections to another set of servers. After leaving it running for a few weeks, its memory usage had grown to 1.5GB. Restarting it reduced its memory usage to expected levels (VSZ and RSS) but while I've been watching it today it has grown by more than 10MB. The stunnel website indicates that there have been fixes relating to memory leaks in versions 5.32 and 5.33, but Ubuntu LTS is still running 5.30. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: stunnel4 3:5.30-1 ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21 Uname: Linux 4.4.0-45-generic i686 ApportVersion: 2.20.1-0ubuntu2.4 Architecture: i386 Date: Mon Jan 9 16:03:37 2017 InstallationDate: Installed on 2015-10-31 (435 days ago) InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release i386 (20151021) ProcEnviron: TERM=xterm SHELL=/bin/bash PATH=(custom, no user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR=<set> SourcePackage: stunnel4 UpgradeStatus: Upgraded to xenial on 2016-05-18 (236 days ago) mtime.conffile..etc.default.stunnel4: 2016-10-26T22:22:28.166247
2017-09-01 05:53:11 Simon Quigley attachment added corrected.debdiff https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1655153/+attachment/4942180/+files/corrected.debdiff
2017-09-01 06:08:50 Simon Quigley removed subscriber Ubuntu Sponsors Team
2017-09-07 20:23:44 Brian Murray stunnel4 (Ubuntu Xenial): status Confirmed Fix Committed
2017-09-07 20:23:46 Brian Murray bug added subscriber Ubuntu Stable Release Updates Team
2017-09-07 20:23:49 Brian Murray bug added subscriber SRU Verification
2017-09-07 20:23:52 Brian Murray tags apport-bug i386 patch xenial apport-bug i386 patch verification-needed verification-needed-xenial xenial
2017-12-08 20:29:57 Ubuntu Foundations Team Bug Bot tags apport-bug i386 patch verification-needed verification-needed-xenial xenial apport-bug i386 patch removal-candidate verification-needed verification-needed-xenial xenial
2018-01-11 15:55:04 Brian Murray tags apport-bug i386 patch removal-candidate verification-needed verification-needed-xenial xenial apport-bug i386 patch removal-candidate verification-done-xenial verification-needed xenial
2018-01-11 17:29:12 Launchpad Janitor stunnel4 (Ubuntu Xenial): status Fix Committed Fix Released
2018-01-11 17:29:16 Brian Murray removed subscriber Ubuntu Stable Release Updates Team
2018-02-28 19:11:06 Dustin Kirkland  tags apport-bug i386 patch removal-candidate verification-done-xenial verification-needed xenial apport-bug i386 patch removal-candidate verification-done-xenial xenial
2018-03-01 17:47:09 Scott Emmons bug added subscriber Netflix Engineering