т.е. все равно записать обязан

хотя да, проморогал что там fflush

Но я скрины кидал, у процесса разрешение на 1м дескрипторов. И в работе примерно 5*число сессий, это 10-20к

При дефолтном 1024 помирало бы сразу

тоже верно

есть этот файлик

Конфиг можно сюда?

конкретно [core] и [log]

Благодарю

а также посмотрите, как кореллирует последнее время модификации лога со временем выхода

Подскажите плиз, по логике работы - может не понимаю чего, а может баг? Модель ситуации - подключается новый абонент. Кабель включили, но в биллинге его пока нет. При access-reject от радиуса абоненту выдается адрес из специального пула, и создается временная сессия. Создается аккаунт. Вот тут бы допустим перегрузить роутер, получить новый dhcp discover, обратиться к биллингу с access-request, и получить новый адрес, но нет! Пока временная сессия не отвалится по таймауту, новые access-request на биллинг не уходят. Неудобненько - приходится или ждать, или придумывать какие-то способы принудительного завершения временной сессии. Это так специально зачем-то задумано?

ну как только учетка завелась , дропайте по mac

или по временному ip

а вообще всем выдают accept  ,если нет пары qinq+ mac, то гостевой IP

ну так оно примерно так и есть - но в момент заведения аккаунта надо же выдать другой ip

про дропать я понимаю, но почему бы не отправить новый access-request, что мешает-то?

Тогда его надо всегда отправлять

может поможет dhcp lease для этого временного IP короткий сделать

но drop я по любому шлю