Peter,
Thanks for the quick reply.
On 2/13/19 13:09, Peter Pentchev wrote:
On Wed, Feb 13, 2019 at 12:17:24PM -0500, Christopher Schultz wrote:
Hello,
I'm new to the list so I'm sorry if this isn't the right place to report this.
I had a server stop responding to stunnel connections sometime yesterday and the resolution was ultimately to reboot the server and everything was okay. Restarting the stunnel service was not enough to get things working again.
[snip]
Looking through the log file, I could see that there were some odd messages coming from stunnel in the daemon.log file suggesting that there might be a memory leak. I won't post them here unless requested, as they may represent a potential security issue.
Hi,
Unfortunately this is a known problem with the Debian package of stunnel; I did not get around to backporting the fixes to the stunnel version that is in Debian 9.x (stretch); I'm really sorry about that.
Confirmed: I'm running Debian Stretch:
$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 9.7 (stretch) Release: 9.7 Codename: stretch
I could make a stretch backport of the stunnel version that is in unstable/testing right now - the one that will be in the upcoming Debian 10.x (buster). Actually I'll build a package later tonight and let you know where you can download it from, then I'll upload it to the stretch-backports suite and wait for the backports admins to accept it. This package will not have the memory exhaustion problem that the version in stretch does have.
That would be great. Will I (eventually) end up getting it via the normal apt update mechanism? I only have these apt sources configured:
deb http://ftp.us.debian.org/debian/ stretch main deb http://security.debian.org/ stretch/updates main
Is there a safe mitigation I can put into place before a patch? I believe Debian's stunnel service scripts completely shut-down one stunnel process and then start up a new one, so I might have a (very short) interruption. I can schedule that via cron if necessary, but I'd prefer to avoid even a small interruption if possible.
Could you just confirm that you are indeed running Debian 9.x (stretch)? (it seems this way from the kernel version that you are running and from the symptoms; stunnel 5.06 in jessie does not have this problem)
I have 5.39. Is this older than 5.06? Or is that a typo?
Sorry again, and thanks for your understanding!
No, it's great to get this kind of feedback right away.
I *am* curious about why a service-restart did not seem to fix things. With the above memory-exhaustion, would you have expected a service-restart to fix everything? (I certainly did.) Is it likely that the "restart" didn't actually restart the service, and I was just repeatedly testing a borked server process?
Thanks, -chris