Em 7 de junho de 2011 20:32, Marcelo Gondim <gon...@linuxinfo.com.br>escreveu:
> Em 07/06/2011 20:13, Hygor escreveu: > > Em 30 de maio de 2011 10:47, Marcelo Gondim<gon...@linuxinfo.com.br > >escreveu: > > > >> Em 30/05/2011 10:13, Welkson Renny de Medeiros escreveu: > >>> Hygor escreveu: > >>>> 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 > >>>> > >>> Você está falando de qual parte Hygor? do daemontools ou do timeout do > >>> banco? > >>> > >>> Se for do daemontools eu concordo! Realmente está mascarando o > problema. > > Estava me referindo ao daemontools... sabendo que o radius está > morrendo.. > > devemos procurar a causa para corrigir... usar um programa para ficar > > levantando o serviço toda vez que ele morre nunca é uma solução... porem > o > > uso do daemontools é uma pratica muito aceita quando não se tem problema > com > > o serviço monitorado. > > Na verdade ele não está morrendo com segfault, simplesmente o serviço > stopa. Sai normalmente. > Em alguns equipamentos isso não ocorre, simplesmente funciona > perfeitamente. Já pesquisei em vários > lugares e tudo indica que pode ser realmente algo com o freeradius. Isso > passou à ocorrer para alguns aqui > depois que mudou-se da versão 7.x para a 8.x no FreeBSD. Para mim isso > foi mais significativo quando mudei para a versão 2.x do freeradius. > > > > >>> Se for do timeout do banco (que eu não sei se vai resolver o problema > >>> dele), talvez não! No meu caso por exemplo (MSN-Proxy), a aplicação não > >>> estava preparada para tentar RECONECTAR ao banco caso a conexão fosse > >>> finalizada por timeout... eu tinha 2 alternativas, ou alterar a > >>> aplicação ou ajustar o banco para evitar esse timeout. > >>> > >>> Eu concordo que em grande hosting não é uma boa prática aguardar 5 dias > >>> para fechar uma conexão por inatividade, afinal está consumindo > recursos > >>> do servidor... mas cada caso é um caso. > >>> > >>> Abraços, > >>> > >> Pois é eu coloquei os timeouts pra 5 dias e vamos ver no que dá. Mas > >> sempre tive esse tipo de problema com radius independente do OS, > >> em algumas máquinas ficava fino e não caía e em outras ocorria esse tipo > >> de coisa. Tentei na época descobrir mas não consegui. Cheguei à trocar > >> memória, placa mãe, processador. > >> Bem estou fazendo o teste do timeout. > >> ------------------------- > >> > > Quantos clientes vc tem cadastrado no radius? > > Nossa base mysql hoje deve ter pra mais de 7000 clientes. Hoje em > horário de pico chegamos à 3000 clientes conectados no PPPoE. > Eu sempre checo diariamente para ver se já saiu alguma versão nova do > freeradius para atualizar e testar. > Pensei em abrir um bug para ele mas o problema é justamente como > reproduzir o problema já que não tem hora certa pra acontecer. > Qual a saida do debug quando o erro acontece? Verifique o tempo de retorno da query que faz o insert do accounting e no select que dá o retorno dos parametros para o NAS > > > ------------------------- > 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