[Bug 1655153] Re: long-running stunnel leaks memory
Simon Quigley
tsimonq2 at ubuntu.com
Fri Sep 1 05:53:11 UTC 2017
Hey Scott! There's a couple of things that are not correct with your patch:
1. "Fixes launchpad bug 1655153." - this is not enough to automatically close the bug report, it should be like this, preferably at the end of the changelog entry: "(LP: #1655153)".
2. Ubuntu is different than Debian in that while it is nice to ask the previous uploader before uploading things, Ubuntu Developers collectively maintain and are responsible for packages. As such, this isn't a non-maintainer upload (I'm an Ubuntu Developer and I acknowledge your change), so it shouldn't have that entry. Also, please change the Maintainer in debian/control as such.
3. The description in the patch should be indented by a space so it is machine-readable.
4. Instead of linking to the commit in "Origin", it should replace "5.33" in "Applied-Upstream".
Since these are literally just changelog and DEP-3 header nitpicks, I've
just fixed it (but indicated above for you to note and attached the
debdiff so you can see exactly what I uploaded) and uploaded it (waiting
for an SRU team member to review it now). :)
Thank you for your contribution to Ubuntu, I really appreciate the
promptness of a follow-up patch and your willingness to fix this bug!
** Description changed:
+ [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>
+ 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.
** Patch added: "corrected.debdiff"
https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1655153/+attachment/4942180/+files/corrected.debdiff
--
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1655153
Title:
long-running stunnel leaks memory
Status in stunnel4 package in Ubuntu:
Fix Released
Status in stunnel4 source package in Xenial:
Confirmed
Status in stunnel4 package in Debian:
Fix Released
Bug description:
[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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/stunnel4/+bug/1655153/+subscriptions
More information about the Ubuntu-sponsors
mailing list