Problemas com sessões expiradas? Não foi possível alocar nova sessão na sessão SSL.

Instalação
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

Isso aconteceu novamente. Vejo que o ssl_session_timeout está definido como 1d em /etc/nginx/conf.d/discourse.conf. Por que ele foi alterado de padrão de 10m para isso?

3

Eu também estou vendo isso nos logs - não muitos, mas eles estão aparecendo. Você encontrou alguma informação sobre essa mudança de configuração ou a reverteu para um período mais curto para você?

4

Provavelmente poderíamos aumentar o tamanho do cache de 1 MB para cerca de 40 MB. Pelo que sei, ele precisa andar junto com o timeout, e aumentamos um sem o outro.

2 curtidas
5

Faz sentido. A alteração do tamanho do cache entrou na lista de alguém?