Isso não seria uma solução.. vc está mascarando o problema.. recomendo vc rodar o radius -X .. usar o debug para corrigir o problema
Hygor Cavalcante FSNETWORK CONSULTORIA Skype: hygorr MSN: hy...@bsd.com.br EMAIL: hy...@bsd.com.br Em 28 de maio de 2011 10:04, Marcelo Gondim <gon...@linuxinfo.com.br>escreveu: > Em 28/05/2011 09:57, Welkson Renny de Medeiros escreveu: > > Marcelo Gondim escreveu: > >> Pois é Hygor também suspeito disso. Eu havia feito um script pra testar > >> se o radius caísse para levantar ele. Mas depois que me indicaram o > >> daemontools aqui na lista, > >> agora fico até mais tranquilo. :) o bichinho é rápido no gatilho. Para > >> quem quiser usar ele no radius eu fiz assim: > >> > >> > > Legal Gondim! > > > > Esse timeout do MySQL também me fez passar por problemas parecidos, mas > > no meu caso não era o FreeRadius (que não uso), e sim o MSN-Proxy e > > servidores de aplicação Java. > > > > Depois de muito apanhar acabei aumentando o timeout do MySQL para 5 dias > > e o problema não voltou a ocorrer (de madrugada nenhum usuário usava o > > sistema, o mysql sinalizava o timeout, e minha aplicação morria). > > > > /var/db/mysql/my.cnf > > > > # correcao para so dropar conexao apos 5 dias de inatividade (default eh > > 8hs) > > [mysqld] > > wait_timeout=432000 > > interactive_timeout=432000 > > > > Um outro parâmetro perigoso é o max_allowed_packet! Dependendo do > > tamanho da instrução SQL o banco também pode cair. > > > Vou colocar esses parâmetros e ver se vai continuar caindo. :) mesmo > porque se cair ele vai levantar mas logicamente se resolver pela raiz do > problema é melhor ainda :) > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
