sudo: incapaz de criar sockets: Não é possível alocar memória

Question

Em um VPS executado pela OVH (aparentemente baseado em OpenVZ, dado que /proc/user_beancounters existe), com relativamente poucos processos em execução, tentar sudo me dá o erro no título.

Aqui está uma transcrição de amostra:

ekleog@ekleog:~$ sudo echo a
[sudo] password for ekleog:
sudo: unable to create sockets: Cannot allocate memory
ekleog@ekleog:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          8.0G       212M       7.8G         0B         0B        43M
-/+ buffers/cache:       168M       7.8G
Swap:         128M         0B       128M
ekleog@ekleog:~$ sudo echo a
sudo: unable to create sockets: Cannot allocate memory

Como você pode ver, não há problema de bifurcação, pois o shell se bifurca para executar free , mas sudo parece não conseguir abrir um soquete. No mesmo domínio, o thunderbird não consegue abrir uma conexão SMTP, mas o ssh continua encapsulando novas solicitações sem qualquer problema.

O fato de o problema ter origem em muitos sockets abertos parece confirmado pelo fato de que, ao fechar o Thunderbird (que mantém algo como 50 conexões para monitorar todas as minhas pastas IMAP), o problema desaparece. Além disso, ao reabri-lo, o problema não se sustenta, então deve haver um vazamento de recursos em algum lugar?

Actualmente tenho apenas um utilizador (eu), por isso espero que as restrições da OVH não sejam tão graves.

Finalmente, durante a "crise", eu tentei executar netstat (não estou acostumado com o seu uso, então posso estar errado):

ekleog@ekleog:~$ netstat -a | wc -l
608
ekleog@ekleog:~$ cat /proc/sys/fs/file-max
1627524

Parece-me estranho que sudo bloqueie.

Você tem alguma ideia de como parar de ter isso? Surge de vez em quando (aprox. Uma vez a cada dois dias) e está ficando muito chato.

Aparentemente, o problema vem das configurações do OpenVZ, como em /proc/user_beancounters , tenho numothersock com um failcnt enorme.

Tentando reduzir o número de soquetes abertos dependendo de cada programa individual, farei perguntas separadas.

    

Answer 1

Vou compartilhar minhas descobertas nesta resposta, esperando que isso ajude alguém no futuro. Estes resultados seriam impossíveis sem a observação imediata no comentário da @ EEAA.

Na verdade, a restrição vem do software OpenVZ. A restrição numothersock pode ser vista em /proc/user_beancounters e de acordo com a documentação: 'Recursos da UBC nos contêineres Parallels Virtuozzo para Linux' :

numothersock - maximum number of non-TCP sockets (local sockets, UDP, and other types of sockets).

Você pode verificar a quantidade de soquetes com ss :

ss is used to dump socket statistics.

ss -xa | wc -l

Para identificar qual processo liga cada soquete:

sudo ss -xap

Para o meu caso específico, verifica-se que mais de 25% da minha restrição em sockets foi devido ao postfix, então eu cortei o default_process_limit parâmetro em /etc/postfix/main.cf (questão relevante aqui ).

    

Answer 2

(Resposta sinônima, mas adicionando algumas informações de diagnóstico e palavras-chave de pesquisa.)

Sintomas

O problema em questão é que nenhum novo soquete não-TCP pode ser criado, o que significa principalmente soquetes de domínio Unix usados para comunicação entre processos no sistema. Pode não ser reproduzível sempre, pois às vezes alguns soquetes são excluídos, abrindo algumas opções para criar novos soquetes abaixo do limite.

Os sintomas não estão restritos ao uso de sudo , mas afetarão a maioria ou todos os sites em execução no servidor e o uso do MySQL por meio de uma conexão de soquete. Mensagens de erro seriam assim:

PDOException: SQLSTATE[HY000] [2001] Can't create UNIX socket (12) in […]
PDOException: SQLSTATE[HY000] [2002] Can't connect to local MySQL server 
    through socket '/var/run/mysqld/mysqld.sock' (12) in […]
PHP Warning:  mysqli_connect(): (HY000/2001): Can't create UNIX socket 
    (12) in […]
PHP Warning:  mysqli_connect(): (HY000/2002): Can't connect to local MySQL 
    server through socket '/var/run/mysqld/mysqld.sock' (12) in […]

Além disso, enviar e buscar e-mails através de postfix resp. O dovecot server provavelmente também falhará no estágio de login. Mensagens de erro incluem:

mailq: fatal: inet_addr_local[getifaddrs]: getifaddrs: Cannot allocate memory

O elemento comum nesses erros é o código de erro 12, que significa "código de erro do sistema operacional 12: não é possível alocar memória", conforme perror 12 [ fonte ].

Solução

Veja a saída de cat /proc/user_beancounters , que mostra os limites do ambiente de virtualização do OpenVZ do seu VPS. Com toda a probabilidade, você verá um grande número de falhas para o limite de recursos numothersock (> 10.000 para mim). Isso significa que um software tentou criar um soquete, mas foi proibido pelo OpenVZ de fazê-lo porque o número máximo de soquetes não-TCP já existia.

Para ver o número e o uso de todos os soquetes contados nesse limite de recursos numothersock , observe o arquivo de saída gerado por:

ss --processes --all --socket=udp,unix,unix_dgram,unix_stream > results.txt 

No meu caso, mostrou que cerca de 80% dos sockets estavam relacionados aos processos postfix e dovecot. Os soquetes relacionados ao postfix podem ser reduzidos para cerca de 10%, limitando o número de conexões simultâneas do padrão 100 para um razoável 10 - veja as instruções . Depois de aplicar essa solução ao postfix ( default_process_limit = 10 ) e reiniciá-la, meus soquetes em uso foram de ~ 1020 para ~ 520 imediatamente. Problema resolvido por enquanto.