andretty

Опять встала костью в горле проблема с ротацией логов... :( Файл заполняется до 2 Гбайт и после этого accel умирает с записью в лог, что файл слишком большой. logrotate файлы меняет но без перезапуска accel толку в этом нет. любые попытки автоматизировать процесс конструкциями echo reload | telnet 127.0.0.1 2000 и echo reload | nc -q0 127.0.0.1 2001 приводят к абсолютно тихой смерти accel: висит еще какое то время в процессах со статусом <defunct>, закрывая соединения, а затем убивается. Причем ни segfault и ни единой строчки в логи об этом факте не падает. Единственное решение, которое проходит - зайти по telnet из консоли и ручками давать reload, что довольно хлопотно... Полагаю, что конструкции, описанные выше у остальных работают без проблем, есть у кого идеи, почему у меня может так происходить? Причем на другой, тестовой машине результат аналогичный. Еще я использую лог по файлам для каждого юзера отдельно и уже предчувствую, что с этим может в скором возникнуть такая же проблема... P.S. предложение+огромная просьба к автору: может имеет смысл встроить в accel функцию ротации собственных логов? Если не ротацию то чтобы мог сам убить лог файл при переполнении, или автоматически перечитывал конфиг через определенный промежуток времени...

Это не проблема, фича ютуба такая

Проблемы с radius :( Версия последняя, из гита cf40442a413d04379711bd73a52372d3a3264ea4 падает практически сразу же после запуска, в dmesg сыпет accel-pppd[16932]: segfault at 58 ip b735566a sp b46ff1f0 error 4 in libradius.so[b734e000+e000] accel-pppd[28263]: segfault at 58 ip b73a266a sp aecf81f0 error 4 in libradius.so[b739b000+e000] accel-pppd[16176]: segfault at 0 ip b75a0d58 sp b06fb21c error 4 in libc-2.13.so[b7482000+159000] accel-pppd[7619]: segfault at 58 ip b751b66a sp ad6f51f0 error 4 in libradius.so[b7514000+e000] accel-pppd[12649]: segfault at 58 ip b74fc66a sp b18fd1f0 error 4 in libradius.so[b74f5000+e000] accel-pppd[13669]: segfault at 0 ip b76add58 sp 896ad21c error 4 in libc-2.13.so[b758f000+159000] Подозрения вызывает ключ req-limit: поставил ограничение на 5 одновременных запросов - поднялось 5 сессий, поставил на 7 запросов - поднялось 7 сессий... Похоже, работает не так, как надо... Когда установил на 0 все пошло как надо, но я не могу оставить 0, т.к. в "часы пик" от перебора запросов авторизации валится уже radius :D Можно как нибудь поправить?

А как бы еще сделать чтобы соединение закрывалось после выполнения команды? А то nc так и остается висеть... Увы, когда применяю подобную конструкцию к telnet 127.0.0.1 2000 то accel-ppp валится, а способ очень востребован

С 1.0.0 он совсем плохо работает - я тоже пробовал (правда еще на релизе 1.3.5). Как решение проблемы я просто поставил dev-libs/openssl-0.9.8s-r1 в новый слот. по утечке памяти пока ничего нового?... Может помочь чем? Еще одна проблемка есть: при закрытии сессии accel-ppp отправляет вместо ip вызывающего абонента какое то некорректное значение, поэтому в базе radius ip записывается как 0.0.0.0 (преобразование не срабатывает).Сегодня включил verbose, постараюсь точно отследить, что он отправляет. UPD: А, нет, прошу прощения. Зря грешил на accel, судя по логам он все нормально отправляет...

Ошибка в man'е по accel-ppp.conf [pppd_compat] Configuration of pppd_compat module. в pppd_compat.c же opt = conf_get_opt("pppd-compat", "radattr-prefix"); if (opt) conf_radattr_prefix = _strdup(opt); получается, в конфиге надо писать через тире [pppd-compat] иначе не работает. Да и по дефолту в префиксе лишняя точка, файлики получаются вида radattr..ppp0 P.S. Это из релиза, accel-ppp-1.5.0

Я тоже пожалуй откат сделаю... а то грохнется ночью :)

Проблема есть. accel-ppp# show stat uptime: 5.10:17:54 cpu: 3% mem(rss/virt): 1653076/2816616 kB core: mempool_allocated: 14404949 mempool_available: 350873 thread_count: 11 thread_active: 1 context_count: 694 context_sleeping: 7 context_pending: 0 md_handler_count: 1906 md_handler_pending: 0 timer_count: 1841 timer_pending: 0 ppp: starting: 0 active: 610 finishing: 0 pppoe: active: 612 delayed PADO: 0 recv PADI: 757975 drop PADI: 0 sent PADO: 757975 recv PADR(dup): 752773(93) sent PADS: 752754 radius(1, 78.109.240.8): request count: 0 queue length: 0 auth sent: 752951 auth lost(total/5m/1m): 965/0/0 auth avg query time(5m/1m): 0/0 ms acct sent: 50810 acct lost(total/5m/1m): 1930/0/0 acct avg query time(5m/1m): 0/1 ms interim sent: 2076516 interim lost(total/5m/1m): 2182/0/0 interim avg query time(5m/1m): 0/0 ms постоянно держит в районе 500 (+/- 150) соединений и за 5 дней съел уже весь своп и 1,6 гига оперативы. Пока сидел на 1.3.5 подобного прожорства не наблюдалось - при той же нагрузке кушал 1,1 Гб оперативки а свопа так вообще не больше 50 Мбайт P.S. Поправьте пожалуйста ebuild'ы для gentoo в 1.5.0 версии :) они там для 1.3.5 и архив с исходниками вручную качать приходится...

я так понимаю скорость нужно менять через CoA ? тогда нужно сконфигурировать dae-server и биллингу сказать чтобы слал запросы на заданный ип:порт,секрет Увы, действительно RADIUS никакого пакета не отправляет, только пишет, что отправляет... Буду мастерить отправлялку

Простите за тупость =) до этого момента не знал, что такое dae server, он не был нужен, поэтому в настройках не указывал. Может, если укажу это решит мою проблему?

можно конечно, но пакет от биллинга явно не приходит, проверь совпадают ли порты и секрет, посмотри снифером куда уходит реально пакет и доходит ли он до наса Порты и секрет совпадают, авторизация то идет нормально, машина рабочая. Радиус сервер и nas стоят на соседних полках, включены в один свитч, в котором одна сеть, сложно представить, что пакет не дойдет физически... я тогда пожалуй поймаю пакет и выложу внутряшку сюда, мож чего интересного найдется, да и подтвердится точно, отправляется он или нет. UPD: accel-ppp 9999 последний из гита dae-server не указан секция radius: (чуть подправил приватные строки, не обессудьте плиз :) ) [radius] dictionary=/usr/share/accel-ppp/radius/dictionary nas-identifier=***** nas-ip-address=x.x.x.x gw-ip-address=x.x.x.x auth-server=y.y.y.y:1812,*секрет* acct-server=y.y.y.y:1813,*секрет* acct-interim-interval=120 verbose=1 timeout=300 max-try=10 acct-timeout=300 #dae-server=127.0.0.1:3799,testing123 #dm_coa_secret=testing123 (deprecated)

Уткнулся я лбом в такую вот бетонную стену: пытаюсь заставить совместно работать модуль dynashape от билинга utm5 и accel-ppp. Основная проблема в динамическом (без дропа ppp сессии) изменении ограничений шейпера на интерфейсе. По докам к utm5 при смене установленных в настройках условий (в моем случае времени суток) radius сервер отправляет NAS'у пакет, содержащий новые значения атрибутов шейпера. Судя по логам utm, он их таки отправляет ... ?Debug : Aug 24 22:00:08 b684fb70 Radius: Got 2 shaping radius attributes ?Debug : Aug 24 22:00:08 b684fb70 Radius: Sending shaping attr slink_id <1566> vendor_id <0> attr_id <230> length <5> ?Debug : Aug 24 22:00:08 b684fb70 Radius: Sending shaping attr slink_id <1566> vendor_id <0> attr_id <231> length <5> ... правда неизвестно (но могу выяснить) каким типом пакета. Но вот accel-ppp наверное игнорирует приходящий пакет (может просто не знает что с ним делать) т.к. по логам и реально, после момента подключения абсолютно ничего не происходило ppp539: 0040de0f53557093: connect: ppp539 <--> pppoe(00:a0:c9:af:4e:84) ppp539: 0040de0f53557093: send [LCP ConfReq id=1 <auth MSCHAP-v1> <mru 1400> <magic 4f5ea0a0>] ppp539: 0040de0f53557093: recv [LCP ConfReq id=1 <mru 1492> <magic b1d6f7e1>] ppp539: 0040de0f53557093: send [LCP ConfAck id=1 ] ppp539: 0040de0f53557093: recv [LCP ConfAck id=1 <auth MSCHAP-v1> <mru 1400> <magic 4f5ea0a0>] ppp539: 0040de0f53557093: send [MSCHAP-v1 Challenge id=1 <5e57e2634e4fc42>] ppp539: 0040de0f53557093: recv [MSCHAP-v1 Response id=1 <000000000000000000000000>, <1d976f33aca5d9deff9108a935c3111dd15c6b5043d0>, F=1, name="andrei"] ppp539: 0040de0f53557093: send [RADIUS Access-Request id=1 <User-Name "****"> <NAS-Identifier "****"> <NAS-IP-Address ****> <NAS-Port 539> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:a0:c9:af:4e:84"> <Called-Station-Id "00:1b:21:2b:6b:e9"> <Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP-Response >] ppp539: 0040de0f53557093: recv [RADIUS Access-Accept id=1 <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-IP-Address ********> <Framed-IP-Netmask 255.255.255.255> <Session-Timeout 86400> <Acct-Interim-Interval 120> <PPPD-Upstream-Speed-Limit "50000"> <PPPD-Downstream-Speed-Limit "50000">] ppp539: 0040de0f53557093: send [MSCHAP-v1 Success id=1 "Authentication successed"] ppp539: 0040de0f53557093: send [iPCP ConfReq id=1 <addr 78.109.240.5>] ppp539: 0040de0f53557093: *******: authentication successed ppp539: 0040de0f53557093: recv [iPCP ConfReq id=1 <addr 0.0.0.0>] ppp539: 0040de0f53557093: send [iPCP ConfNak id=1 <addr **************>] ppp539: 0040de0f53557093: recv [iPCP ConfAck id=1 <addr **************>] ppp539: 0040de0f53557093: recv [iPCP ConfReq id=2 <addr **************>] ppp539: 0040de0f53557093: send [iPCP ConfAck id=2] ppp539: 0040de0f53557093: send [RADIUS Accounting-Request id=1 <User-Name "******"> <NAS-Identifier "******"> <NAS-IP-Address ************> <NAS-Port 539> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:a0:c9:af:4e:84"> <Called-Station-Id "00:1b:21:2b:6b:e9"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53557093"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address ***************>] ppp539: 0040de0f53557093: recv [RADIUS Accounting-Response id=1] ppp539: 0040de0f53557093: pppd_compat: ip-up started (pid 4543) ppp539: 0040de0f53557093: pppd_compat: ip-up finished (0) Подскажите пожалуйста, как можно заставить accel-ppp изменять ограничения шейпера на определенном интерфейсе при получении такого пакета, или как минимум обновления файла radattr.ppp*?

Можно и так. Если настроить syslog на логирование в отдельный файл то это вполне устроит, хотя и теряется возможность разбивать main и debug логи. P.S. да и вообще честно говоря формат лога мягко сказать, мм.. не user-friendly :)

Товарищи! Подскажите, как быть с логами? После ротации accel-pppd пишет по старому дескриптору, конструкция, предложенная товарищем lan-viper тут вызывает у меня падение accel-pppd и получается у меня такая вот безрадостная картинка :( ~ # ls -lh /var/log/accel-ppp/ ............... -rw-rw-rw- 1 root root 0 Июл 22 14:01 accel-ppp.log -rw-rw-rw- 1 root root 837M Авг 4 17:16 accel-ppp.log.1 -rw-rw-rw- 1 root root 2.0G Июл 2 00:11 accel-ppp.log.10 -rw-rw-rw- 1 root root 527M Июл 22 02:22 accel-ppp.log.2 -rw-rw-rw- 1 root root 51M Июл 22 02:22 accel-ppp.log.3 -rw-rw-rw- 1 root root 38M Июл 7 00:09 accel-ppp.log.4 -rw-rw-rw- 1 root root 23M Июл 6 15:39 accel-ppp.log.5 -rw-rw-rw- 1 root root 116M Июл 6 13:27 accel-ppp.log.6 -rw-rw-rw- 1 root root 105M Июл 5 05:15 accel-ppp.log.7 -rw-rw-rw- 1 root root 170M Июл 4 13:17 accel-ppp.log.8 -rw-rw-rw- 1 root root 176M Июл 3 00:11 accel-ppp.log.9 ......... Тоесть лог, как ни печально, ротируется только после перезапуска. Слава богу, что если telnet'ом подключиться к 2001 порту то вручную reload работает нормально, но следить за файлом и делать это вручную каждый раз когда он дорастет до нужной величины как то совсем не катит :(

Еще одна трабла, пускай и не такая критичная: как быть с ротацией логов? Ротирую через logrotate, после подмены accel-pppd продолжает писать в старый файл...