O Moodle deixou de aceitar novas conexões

O servidor continuava respondendo aos testes básicos, porém novas páginas falhavam para centenas de usuários porque todos os processos disponíveis do PHP já estavam ocupados, uma diferença que explicava por que o monitoramento simples dizia que a máquina estava no ar enquanto ninguém conseguia trabalhar.

O primeiro cuidado foi preservar o cenário como ele aparecia naquele momento, conferimos se o endereço usado estava correto, se a conta permanecia ativa, qual método de autenticação estava atribuído, quando havia ocorrido o último acesso bem sucedido e se a falha atingia apenas aquele usuário ou todos que dependiam do mesmo serviço, porque redefinir a senha novamente poderia apenas esconder por alguns minutos uma inconsistência de LDAP, SSO, certificado ou cadastro.

Quando já sabíamos quem era afetado, reproduzimos o login em uma sessão limpa e acompanhamos os registros gerados desde o envio do formulário até a resposta do provedor de identidade, comparando a conta afetada com outra do mesmo perfil que ainda conseguia entrar e verificando horário, origem, retorno recebido e mudanças recentes na configuração.

A causa apareceu quando colocamos lado a lado o que funcionava e o que falhava, pois o resumo inicial de que o limite de processos do PHP foi atingido e centenas de usuários passaram a receber erro mesmo com o servidor ainda ativo. passou a coincidir com uma diferença concreta encontrada no caminho da autenticação, então a correção foi testada primeiro de forma controlada e depois repetida com perfis distintos para garantir que o acesso havia voltado sem abrir permissões além do necessário.

Confirmamos o limite atingido, identificamos as requisições que mantinham os processos presos e recuperamos o atendimento de forma controlada, depois a infraestrutura ajustou capacidade e alertas enquanto as rotas mais demoradas foram analisadas para que aumentar o limite não servisse apenas para adiar a próxima saturação.