🚀 go-pugleaf

czajka.tomek@gmail.com <czajka.tomek@gmail.com> napisał(a):
> Witam!
> Zainstalowany freeradius 2.1.4 + postgresql. 2000-3000 userów.
> Wszystko działa bezproblemowo do momentu kiedy musi się autoryzować w
> jednym czasie większa liczba użytkowników (zdarza się tak gdy np w
> jeden części sieci wysiadł na chwilkę prąd i po przywróceniu zasilania
> próbuje się autoryzować np 200-300 uzytkowników w jednym czasie).
> Problem polega na tym że wywala się całkowicie proces serwera radiusd.
> Zero informacji w logach, poprostu jak dostaje taką burzę zapytań o
> autoryzację wywala się bez echa i najgorsze jest to że zanim wszyscy
> się autoryzują potrafi się kilkukrotnie ubić proces więc ręcznie
> trzeba go podnosić aż wszyscy dokonają autoryzacji.
> Spotkał się ktoś z takim problemem? Jakieś pomysły na rozwiązanie?

Rozwiązanie "młotkowe" - respawnować proces po padzie. Puść go
ze skrypta w nieskończonej pętli z parametrem -f.
Coś w stylu:
while true; do radiusd -f; date >> radpad.log; sleep 1; done

Rozwiązanie lepsze, jak już masz pada i oczekujesz następnego,
to puść go przez strace i zobacz na czym się wywala.

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>

On 15 Maj, 11:48, Konrad Stepien <xba...@vagreqngn.arg.cy> wrote:
> czajka.to...@gmail.com <czajka.to...@gmail.com> napisał(a):
>
> > Witam!
> > Zainstalowany freeradius 2.1.4 + postgresql. 2000-3000 userów.
> > Wszystko działa bezproblemowo do momentu kiedy musi się autoryzować w
> > jednym czasie większa liczba użytkowników (zdarza się tak gdy np w
> > jeden części sieci wysiadł na chwilkę prąd i po przywróceniu zasilania
> > próbuje się autoryzować np 200-300 uzytkowników w jednym czasie).
> > Problem polega na tym że wywala się całkowicie proces serwera radiusd.
> > Zero informacji w logach, poprostu jak dostaje taką burzę zapytań o
> > autoryzację wywala się bez echa i najgorsze jest to że zanim wszyscy
> > się autoryzują potrafi się kilkukrotnie ubić proces więc ręcznie
> > trzeba go podnosić aż wszyscy dokonają autoryzacji.
> > Spotkał się ktoś z takim problemem? Jakieś pomysły na rozwiązanie?
>
> Rozwiązanie "młotkowe" - respawnować proces po padzie. Puść go
> ze skrypta w nieskończonej pętli z parametrem -f.
> Coś w stylu:
> while true; do radiusd -f; date >> radpad.log; sleep 1; done
>
> Rozwiązanie lepsze, jak już masz pada i oczekujesz następnego,
> to puść go przez strace i zobacz na czym się wywala.
>
> --
> WARNING: my e-mail is encrypted by ROT13
> Xbaenq Fgrcvra <xba...@vagreqngn.arg.cy>

Dzięki za odpowiedź.
Rozwiązanie "młotkowe" zawsze można zastosować, jednak wolałbym
wiedzieć co go boli. Z strace jeszcze nie próbowałem, ale sprawdzę to.
Dzisiaj znów freeradius wyleciał, zostawił jednak po sobie ślad

pid 7009 (radiusd), uid 133: exited on signal 11
#define SIGSEGV         11      /* segmentation violation */

Jakiś pomysł?
pozdrawiam

czajka.tomek@gmail.com <czajka.tomek@gmail.com> napisał(a):
> On 15 Maj, 11:48, Konrad Stepien <xba...@vagreqngn.arg.cy> wrote:
>> czajka.to...@gmail.com <czajka.to...@gmail.com> napisał(a):
>>
>> > Witam!
>> > Zainstalowany freeradius 2.1.4 + postgresql. 2000-3000 userów.
>> > Wszystko działa bezproblemowo do momentu kiedy musi się autoryzować w
>> > jednym czasie większa liczba użytkowników (zdarza się tak gdy np w
>> > jeden części sieci wysiadł na chwilkę prąd i po przywróceniu zasilania
>> > próbuje się autoryzować np 200-300 uzytkowników w jednym czasie).
>> > Problem polega na tym że wywala się całkowicie proces serwera radiusd.
>> > Zero informacji w logach, poprostu jak dostaje taką burzę zapytań o
>> > autoryzację wywala się bez echa i najgorsze jest to że zanim wszyscy
>> > się autoryzują potrafi się kilkukrotnie ubić proces więc ręcznie
>> > trzeba go podnosić aż wszyscy dokonają autoryzacji.
>> > Spotkał się ktoś z takim problemem? Jakieś pomysły na rozwiązanie?
>>
>> Rozwiązanie "młotkowe" - respawnować proces po padzie. Puść go
>> ze skrypta w nieskończonej pętli z parametrem -f.
>> Coś w stylu:
>> while true; do radiusd -f; date >> radpad.log; sleep 1; done
>>
>> Rozwiązanie lepsze, jak już masz pada i oczekujesz następnego,
>> to puść go przez strace i zobacz na czym się wywala.
>
> Dzięki za odpowiedź.
> Rozwiązanie "młotkowe" zawsze można zastosować, jednak wolałbym
> wiedzieć co go boli. Z strace jeszcze nie próbowałem, ale sprawdzę to.
> Dzisiaj znów freeradius wyleciał, zostawił jednak po sobie ślad
>
> pid 7009 (radiusd), uid 133: exited on signal 11
> #define SIGSEGV         11      /* segmentation violation */
>
> Jakiś pomysł?
> pozdrawiam

Jak dumpnął core, to wyślij do autorów.
Segfault to ewidentny babol w kodzie (albo problem ze sprzętem).

-- 
WARNING: my e-mail is encrypted by ROT13
Xbaenq Fgrcvra <xbaenq@vagreqngn.arg.cy>