Erro estranho no Squid [RESOLVIDO]

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 11:00h

Vou monitorar, obrigado pela força... daqui a pouco eu dou o feedback!

Buckminster
(usa Debian)

Enviado em 27/01/2016 - 11:10h

Por via das dúvidas execute

# cat /proc/sys/fs/file-max

e veja qual o valor que está atualmente.

Caso queira aumentar execute

# vim /etc/sysctl.conf <<< usei o vim, use teu editor preferido

e acrescente no final a linha

fs.file-max = 791122

Salve e saia do arquivo e execute

# sysctl -p /etc/sysctl.conf

e depois confira

# cat /proc/sys/fs/file-max

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 11:15h

Aumentei os limites, vamos ver se agora resolve...

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 11:16h

A saída do comando cat /proc/sys/fs/file-max foi "391793"

Buckminster
(usa Debian)

Enviado em 27/01/2016 - 11:47h

Coloque 791122, reinicie a máquina e teste.

E poste aqui qual o domínio que tu incluiu na lista antes de dar o erro.

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 12:29h

Não tenho como reiniciar essa máquina agora, mas eu executei "ulimit -n 65536" e até agora não deu mais problemas...

Buckminster
(usa Debian)

Enviado em 27/01/2016 - 12:46h

O Squid tem um limite de comprimento de string fixado em 64 KB (~65536).
O comando ulimit limita a quantia de recursos que podem ser usados. Os limites são configurados para cada usuário, mas são aplicados separadamente a cada processo que está em execução para esse usuário.

Executando ulimit -n 65536 tu limitou para essa quantia TODOS os serviços que estão rodando na máquina.
E lembre-se, o comando ulimit é somente para essa sessão, ao reiniciar a máquina volta como era antes.
Como é Debian talvez tu deva colocar esse comando no rc.local.

Mas monitore para ver se não dará problemas em outros serviços da máquina.

E execute

# ulimit -a

e veja a saída.

Mas ainda acredito que o problema está relacionado ou àquele domínio que tu adicionou ou a alguma outra alteração que tu fizeste no servidor, alteração esta que talvez nem tenha sido no Squid, mas que consumiu os recursos do sistema e acabou prejudicando o Squid.
Essas são as minhas suspeitas.
Se der o mesmo erro de novo, veja também o arquivo /var/log/messages.

http://ss64.com/bash/ulimit.html

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 14:15h

ulimit -a:

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 30611
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 30611
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Curioso que antes de eu executar o ulimit -n 65536, o ulimit estava em 1024... deu uma reduzida nos crashes, mas aconteceu mais uma vez.... o domínio adicionado foi .live.com porque os usuários do Skype não estavam conseguindo se comunicar com os contatos do hotmail... a única alteração foi essa...

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 14:22h

Dessa última vez teve um segfault antes:

kernel: [47211422.861330] squid3[11271]: segfault at ffffffffffffffe8 ip 00007f7882527487 sp 00007fff8c304d80 error 5 in squid3[7f7882113000+53d000]

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 14:31h

Existe alguma forma de se aumentar esse limite? O que será que está causando esse buffer overflow?

r.garcia
(usa Ubuntu)

Enviado em 27/01/2016 - 15:57h

Bom, mudei os outros parâmetros que você passou e desde as 13:48 não teve mais nenhuma queda... se continuar assim amanhã eu encerro o tópico!!!

Muito obrigado pela força!!!

Buckminster
(usa Debian)

Enviado em 27/01/2016 - 18:43h

Não tem como mudar isso. Está no código fonte.