Работает * и в какойто момент появляется второй процесс asterisk, который хавает 99% проца, при этом первый перестаёт обрабатывать voip события и глухо виснет.
Откуда берётся этот второй процесс и при каких манипуляциях пока установить не смог. Но как только его убиваю всё начинает нормально работать..
Может быть ктото сталкивался ?
Версия * 1.4.20.1 (так же было замечена и на более ранних)
FreeBSD 6.3

Все вызовы проходят через AGI скрипты.. пожалуй, это единственное на что можно спихнуть проблему, но уверенности нет.

Немного поизучал ситуацию.
Выяснилось что косяк действительно в AGI.
Причем простейший скрипт, который всего лишь берёт из STDIN переменные звонка рано или поздно стопорит *.
На многопроцессорной системе это приводит к клонированию процесса, который забирает 100% ресурсов процессора, на однопроцессорной системе вешается основной процесс. Звонки перестают, ходить, но консоль (asterisk -r) при этом жива.
Скрипт написан на перл.

Использовал примерно так
exten => _X.,1,AGI(test.pl)
exten => _X.,n,Dial(${EXTEN})

сам скрипт
#!/usr/bin/perl

use strict;
$|=1;

my %AGI;


while(<STDIN>) {
chomp;
last unless length($_);
if (/^agi_(\w+)\:\s+(.*)$/) {
$AGI{$1} = $2;
}
}


Такое поведение замечено начиная с версии 1.4.9, другими словами с самого начала знакомства с *
ОС - FreeBSD


Интересно, ктонить изпользует * без AGI?

немного наврал - через скрипт который выше астер работает штатно.
как только я добавил в скипт "use DBI;" для использования запросов в БД не прошло и 10 минут после чего * вылетел в кору.

Используйте FastAGI. Даже если сервер на той же машине. Это позволяет один раз породить процесс, инициализировать базу данных, и далее либо порождать потоки для отработки запросов, либо вообще применить асинхронную модель и делать все в рамках одного процесса. А когда будет достигнут лимит, FastAGI сервер просто переносится на другую машину.

Читаете мысли, обязательно попробую и отпишу.
Дело в том, что на скорую руку я уже пробовал FastAGI на базе того скрипта, который уже есть - результаты были похожими, но сейчас я намерен выяснить всё до конца.

Я использую строко FastAGI. И пока строго на Python :-)

Питон я уже начал изучать ))

В общем что имею - запустил FastAGI, проблем сразу не возникло, модуль Mysql багов не вызывал, скрипт выполнял несколько запросов. После каждого небольшого изменения давал системе поработать, дабы удостовериться, что в написанном коде не возникнет опять затупов. Как только я начал выполнять из скрипта Dial астер снова начал тупить и кушать проц (( думаю как обойти. В скрипте эта команда может использоваться не раз, поэтому вариант проставлять переменные канала и выходить для того чтобы сделать Dial из диалплана астериска не катит..
Вот только что астер вообще вывалился в кору (уже с убранной Dial из скрипта)..

PS можешь поделить небольшим скриптом на python для примера ? я так понимаю ты юзаешь pyst ?

В общем пока я склонен полагать, что баг генерит вызов agi->exec(...) перлового модуля..

#!/usr/local/bin/python

import time
import asterisk.agi

agi = asterisk.agi.AGI()
t = time.localtime()

agi.appexec("Monitor","wav|/var/spool/asterisk/monitor/" + str(t[0]) + "/" + str(t[1]) + "/" + str(t[2]) + "/\
" + str(t[3]) + "-" + str(t[4]) + "-" + str(t[5]) + "_" + agi.env['agi_context'] + "_" + agi.env['agi_callerid'] + "_" + agi.env['agi_extension'] + "|bm")




скрипт стоит с приоритетом 1 перед каждым звонком
через 5 минут работы * вываливается в кору.
потерял надежду на *, ушёл курить YATE

Уделил ещё немного времени проблеме, в результате нашёл причину.
Процесс после выполнения определённых операций с управлением потоками зависал в состоянии umtxn, трейс показал такое
(gdb) bt
#0 0x00000000409d08da in _umtx_op () from /lib/libc.so.7
#1 0x0000000040ba5c9a in pthread_cleanup_push () from /lib/libthr.so.3
#2 0x0000000040ba231b in pthread_mutex_getprioceiling () from /lib/libthr.so.3
#3 0x0000000040774324 in WorkerThread (arg=0x40770d20) at src/ThreadPool.c:440
#4 0x0000000040b9f459 in pthread_getprio () from /lib/libthr.so.3
#5 0x0000000000000000 in ?? ()

Это всё происходило в системе FreeBSD 7-Release, а там по умолчанию libthr.
Пересобрал * с libpthread и проблема ушла.

# ldd /usr/local/sbin/asterisk
/usr/local/sbin/asterisk:
libncurses.so.6 => /lib/libncurses.so.6 (0x28151000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x28190000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x28283000)
libm.so.4 => /lib/libm.so.4 (0x2834e000)
libpthread.so.2 => /lib/libpthread.so.2 (0x28364000)
libc.so.6 => /lib/libc.so.6 (0x28389000)

Пока 2 дня аптайма без единого косяка, продолжаю нагружать систему и наблюдать за поведением.