Closed rmoesbergen closed 6 years ago
Thanks for reporting this, fixed and will be part of the next update.
Note:
Thanks! The reason I switched back to memcached is that, after upgrading to 2.1.7/6.9.1 uwsgi kept restarting for unknown reasons and lost all session info (since the new cache runs in uwsgi). I'm still investigating why these restarts happen, will let you know when I find something.
The restart is because the configuration is dynamic not static. When a usgi node comes up and registers itself with consul it then needs to talk to any other members of the cluster and they need to accept connections from it. A process listens for consul updates and generates a new uwsgi configuration that adds or removes the node that has joined or left. The uwsgi process needs to be reloaded when a configuration change happens.
We have not heard of any issues on small clusters of about 3 nodes, maybe you have a larger one which presents a different issue ?
Aha, that explains a lot. Indeed, it only happens on the 16-node cluster, all the 3 node ones are running fine without memcached.
on the 16 node cluster, the consul cluster wasn't stable. After opening up some more firewall ports, it seems to have stabilized. I'll try to go back to the built-in cache, and see if uwsgi keeps running now. Thanks for the explanation.
For the 'web' and 'mail' roles in a cluster, the stunnel configuration for memcached is incorrect: For memcached to work, I had to change this:
[cache] client = yes accept = 127.0.0.1:11211 connect = 62.112.253.54:11211 verifyChain = yes CAfile = /etc/pki/stunnel-ca/certs/stunnel-ca.pem
to this: [cache] client = yes connect = 62.112.253.54:11211 verifyChain = yes CAfile = /etc/pki/stunnel-ca/certs/stunnel-ca.pem accept = /var/run/stunnel/memcached.sock setuid = baruwa setgid = baruwa
With the default config, uwsgi complains that it cannot connect to unix://var/run/stunnel/memcached.sock and the web-frontend doesn't work.