Trouble with stale sessions? could not allocate new session in SSL session

installation
1

I’m not sure what’s up here; it might be a bug. I have a couple of sites that are getting spurious errors like these:

2021/09/29 12:46:34 [alert] 11364#11364: *1226080 could not allocate new session in SSL session shared cache "SSL" while SSL handshaking, client: x.x.42.250, server: 0.0.0.0:443

One one of them I contrived to increase max sessions like this:

  after_bundle_exec:
    - replace:
       filename: "/etc/nginx/nginx.conf"
       from: "  worker_connections 768;"
       to: "  worker_connections 1280;"
  after_letsencrypt:
    - replace:
       filename: "/etc/nginx/letsencrypt.conf"
       from: "  worker_connections 768;"
       to: "  worker_connections 1280;"

I thought that it had fixed it (didn’t see any such errors the next day), but now I’m seeing them again on that site.

This is somewhat out of my wheelhouse, but my best guess is that somehow a bunch of connections are staying active rather than being dropped and nginx is running out of sessions?

Both are standard installs and don’t have especially high traffic. One is a 4GB something on AWS the other an 8GB DO droplet (about 40K pageviews/day). I’ve got other sites with much more traffic and I don’t remember ever seeing this before, so I’m wondering if there is something new going on here.

2

This happened again. I see that the ssl_session_timeout is set to 1d in /etc/nginx/conf.d/discourse.conf. Why is it changed to this from the default of 10m?

3

I am seeing those in the log too - not too many but they are coming up. Did you find any info about that config change or did you change it back to a shorter timeframe for yourself?

4

We could probably bump the cache size from 1MB to 40MB or so. AFAIK it needs to walk in hand with the timeout, and we did bump one without the other.

2 Likes
5

That makes sense. Did changing the cache size get on someone’s list?