ACCT_TERMINATE_CAUSE 3 : Lost-Service

[ran]

с недавнего времени начал появляться сабж в / Клиенты/ Логины/ Информация/ Сервисы/ Internet/ Статистика/

при этом усер на самом деле остаётся подключённым (туннель на него поднят) но в мониторинге впн его нету

вот щас например по поднятым туннелям у меня в онлааайне где-то так усеров 300 а в мониторинге - 50 у остальных как-бы сессии завершены с сабжем

по большому счёту не сильно-то и беспокоит (трафик-то у меня ипн считает а ему пофиг сессии)... просто смотрю - что-то в мониторинге народу нету... забеспокоился... а народ-то на самом деле в наличии (судя по туннелям и проходящему по ним трафику)

базу чекал - ошибок нет...

ЗЫ: если пристрелить туннельный сервер (а он у меня сам пристреливает дочерние пппд роцессы) а потом запустить снова - некоторое время всё ок (туннели соответствуют мониторингу)... потом через какое-то время опять сабж с реально работающими туннелями и отсутствием сессий в монике...

ЗЫ2: похоже дело обстоит так: усер подключается, появляется в мониторинге впн, потом через время (скажем полчаса) абиллс считает сессию завершённой по причине лост-сервис что и записывается в статистику впн, исчезает естественно из мониторинга, но туннель остаётся рабочим... да собственно сессия и не должна была завершиться - у биллинга нет оснований согласно ТП и депозита усера его рубить... его traffic2sql обрубит при необходимости пристрелив соответствующий пппд процесс...

чушь какая-то... абиллс ещё из январского снапшота... никакого существенного софта на этот сервер давно уже не ставил а началось это недавно - точно сказать не могу - как-то мне даже в голову не приходило проверять соответствие к-ва туннелей к-ву народа в мониторинге

кстати что такое лост-сервис? алайвы что ли перестают ходить/теряются?

кстати из этого следует, что усер с лост-сервис но оставшимся живым туннелем сможет подключиться повторно потому как абиллс не знает что сессия на самом деле-то жива... правда поскольку ипы у меня статические на дубликатный туннель назначится соответственно дубликатный ип и именно 2-й туннель будет нерабочим потому как дубликатный маршрут на дубликатный ип окажется в таблице маршрутизации после 1-го

[ran]

а проблемка я думаю в этом:

Mon Aug 17 00:10:47 2009 : Info: The maximum number of threads (32) are active, cannot spawn new thread to han
dle request
Mon Aug 17 00:10:47 2009 : Error: WARNING: Unresponsive child (id 2905602960) for request 165482 (in component
accounting module rlm_perl)
Mon Aug 17 00:10:47 2009 : Error: WARNING: Unresponsive child (id 2897210256) for request 165483 (in component
accounting module rlm_perl)

только вот...

1. чего и сколько ему нада сконфигурировать в зависимости от к-ва он-лайн клиентов (ну не методом же научного втыка тем более на БОЕВОМ серваке)

2. а как-нить можно заставить абиллс в лог ошибок хотяб какие-нить матюги про лост-сервис писать... а то системные логи лопатить... как-то не того...

[sopov]

Попробуй увеличить время acct update до 300 секунд

[ran]

Попробуй увеличить время acct update до 300 секунд

попробую... а мож всё-таки ресурсов радиусу в конфиге подкинуть?

[ran]

стопки... Mon Aug 17 00:10:27 2009 - это ж база по крону бекапится... канешна там локи... начит дело не в этом...

[NiTr0]

Очевидно, скрипты ждут окончания бекапа - а бекап, возможно, длится длительное время - биллинг сессии переводит в зап, а после - дропает. Особенно, если малое кол-во lost alive пакетов указано

[ran]

Очевидно, скрипты ждут окончания бекапа - а бекап, возможно, длится длительное время - биллинг сессии переводит в зап, а после - дропает. Особенно, если малое кол-во lost alive пакетов указано

та не... это понятно... я просто на время в логах сначала внимания не обратил... просто эти записи к ситуёвине отношения не имеют... а ситуёвина, описанная в 1 посте имеет место быть - у меня и сейчас к-во живых туннелей больше чем записей в монике... "лишние" по абиллсу как бы завершены по лост-сервис

а вот когда это происходит и почему шото не соображу как отлавливать

[NiTr0]

а вот когда это происходит и почему шото не соображу как отлавливать

Когда - узнать не проблема, просмотрев статистику алайв пакетов. А потом уже думать почему...

[ran]

а вот когда это происходит и почему шото не соображу как отлавливать

Когда - узнать не проблема, просмотрев статистику алайв пакетов. А потом уже думать почему...

хм... дык в том то и дело что в /var/log/radius/radacct/127.0.0.1/detail-* Acct-Terminate-Cause = Lost-Service нету... да и не будет их там потому как ето завершение не по приходу стоп пакета

[NiTr0]

Времяч можно узнать, посмотрев приход последнего алайва

[ran]

Времяч можно узнать, посмотрев приход последнего алайва

да его можно узнать из детальной статистики впн... сессия то была завершена по лост-сервис... только что оно даёт? 1 усер проработал 2 часа - потом лост-сервис по абиллсу и продолжение работы на самом деле... другой 15 минут... закономерности никакой

[Dozz]

Я сабж и несоответствие количества реальных юзеров количеству в мониторинге замечать стал еще месяца 2 назад с менеджером безспроводных точек доступа в качестве НАСа. Грешил в основном на него. Получается, что случайным образом (особенно при неуверенном покрытии сети) от юзера не приходят алайвы, биллинг закрывает его сессию с ACCT_TERMINATE_CAUSE=Lost-Service, после чего из мониторинга юзер пропадает, а реально использует дальше интернет на халяву.

Вроде ситуацию спасло поднятие Acct-Interim-Interval до 300 и Alive до 60 сек, хотя не уверен. До сих пор проблема возникает время от времени.

Есть идеи или рекомендации?

[NiTr0]

поднятие Acct-Interim-Interval до 300 и Alive до 60 сек

А ничего, что при этом биллинг будет ждать алив-пакеты каждую минуту, а радиус - слать их каждые 5 минут?

[Dozz]

поднятие Acct-Interim-Interval до 300 и Alive до 60 сек

А ничего, что при этом биллинг будет ждать алив-пакеты каждую минуту, а радиус - слать их каждые 5 минут?

Acct-Interim-Interval - это ж время, через которое биллинг делает пересчет статистики пользователя, инициированное радиусом. Разве оно как-то связано с алайв-пакетами, которые клиент обязуется посылать каждые 60 (в данном случае) секунд для оповещения сервера о своем присутствии. Исправьте меня, если я неправ.

[NiTr0]

Acct-Interim-Interval - это ж время, через которое биллинг делает пересчет статистики пользователя, инициированное радиусом. Разве оно как-то связано с алайв-пакетами, которые клиент обязуется посылать каждые 60 (в данном случае) секунд для оповещения сервера о своем присутствии. Исправьте меня, если я неправ.

Acct-Interim-Interval - это атрибут, передаваемый радиус-клиенту. Который как раз и указывает, как часто клиент будет слать алайв-пакеты.
Поле алайв - только для биллинга актуально, клиент о его существовании даже не подозревает