[FUG-BR] Freeradius caindo parte II [Resolvi assim]
Hygor
hygor em vipway.com.br
Quarta Junho 8 02:03:33 BRT 2011
Em 7 de junho de 2011 20:32, Marcelo Gondim <gondim at linuxinfo.com.br>escreveu:
> Em 07/06/2011 20:13, Hygor escreveu:
> > Em 30 de maio de 2011 10:47, Marcelo Gondim<gondim at 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: hygor at bsd.com.br
> >>>> EMAIL: hygor at 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
>
>
Mais detalhes sobre a lista de discussão freebsd