crypto/stack/stack.c:209: 80595 allocations stunnel: LOG4: Possible memory leak at. crypto/asn1/asn1_lib.c:327: 208706 allocations stunnel: LOG4: Possible memory leak at. crypto/asn1/tasn_new.c:122: 285606 allocations stunnel: LOG4: Possible memory leak at. crypto/asn1/asn1_lib.c:295: 318560 allocations stunnel: LOG4: Possible memory leak at. So I checked the logs and found these error messages repeatedly showing up: stunnel: LOG4: Possible memory leak at. So I took a screenshot of the console and it showed a screen filled with out-of-memory errors. Everything is great right? Well, not so fast!Ībout a day or two later, a co-worker contacted me and informed me that the docker host running the web application was down. ( Side Note: options = NO_SSLv2 is not a valid config and will cause stunnel to not start properly) Within the matter of minutes, I had stunnel setup properly for the application to start connecting to Redis via my specified localhost port.
STUNNEL DEPENDENCIES HOW TO
I had setup stunnel similarly to what’s outlined in AWS’s documentation on how to connect to Elasticache for Redis with stunnel along with a few tweaks of my own. Once upon a time, on a sunny Saturday, I was happily working on a client’s web application that was switching over to Redis for caching. What does that mean?įor those of you who are unfamiliar with the term, what a memory leak will essentially do is that it won’t release unneeded RAM from past activity while allocating more RAM for new activity until your container or VM no longer has anymore to use causing your workload to at some point become completely unresponsive. Do you have production workloads running on Ubuntu 18.04? Are you switching your caching to Redis or more specifically configuring an application like Magento with no built-in tls support for Redis (as far as I know) to use AWS Elasticache? If you are, you will run into the same problem as I did where the latest stunnel that comes stock on this Ubuntu release has a known memory leak.
0 kommentar(er)
