AF
Asterisk Forum
обсуждения телефонии, VoIP и IP-PBX
12разделов
5 423тем
34 385сообщений
← К списку тем

Виснет Asterisk

Newbies/FAQ Forum 56 сообщений 11.01.2011 12:53 - 10.11.2011 22:07
#1 11.01.2011 12:53

Виснет Asterisk

В общем есть ubuntu server 10.10 + asterisk 1.8.1.1 + dahdi + freepbx 2.8
раньше стояло на centos, дистриб готовый asterisknow. но возникла необходимость переехать.
все поставил, все настроил.
имеется 30 юзверов. штук 10 внешних номеров.

перед переездом несколько раз в виртуалке пробывал поднимать систему.

проблема возникает следующая. после некоторого времени (может почти двое суток, а может и через час) asterisk просто перестает работать.
звонки не принимает, юзверов тоже. freepbx висит при попытке открыть.
apache впорядке, хост phpmyadmin спокойной открывается.
при этом в консоль asterisk захожу и могу регистрации посмотреть, например.

последний раз, в момент повисания, был один входящий звонок.

в putty зашел в консоль астериска до повисания с параметром -vvvvvv
в момент повисания в логах ничего не обнаружено. так же просмотрел все логи в системе, ничего не нашел подозрительного

может кто-то сказать куда копать?

гуглем не нашел вообще ни чего подобного 0_о
#2 11.01.2011 16:39
Железо кривое
_________________
Intel Core 2 Duo E6400 @ 2.40GHz / 6GB / 160GB
Gentoo Linux || Asterisk 1.8.5 | SFA | FFA | Datacard
#3 12.01.2011 05:04
посмотри sip show channels, есть ли залипшие соединения в состоянии INVITE или BYE
#4 12.01.2011 06:13
присоединяюсь к проблеме...
происходит аналогичная ситуация. но работают клиенты с sip по tcp, только udp перестают.
причем началось не так давно, в проекте сервер работал с 2007-го года без проблем.
#5 12.01.2011 08:07
aven wrote:
Железо кривое

с железом все ок. на CentOS сбоев не было.


вот сейчас повис астериск в очередной раз.. проверил, как подсказал ZloMurz, sip show channels
увидел около 5, по всей видимости, залипших каналов

возникает вопрос, почему они могут залипать?


UPD: почитал на форуме и наткнулся на инфу, что вероятнее всего cdr на mysql вешает звонки %)
#6 12.01.2011 10:41
Самый простой и варварский способ - раз в день перегружать сервер. У меня один такой пациент есть.
2aven
Кривое железо? Просто интересно, как, в зависимости от железа могут падать только определенные программы, а не вся система.
_________________
Asterisk 1.4.30 @ Ubuntu 9.04 + Cisco MC3810 + NEC NEAX 2000IPS + Polycom IP Phones
#7 12.01.2011 10:45
у меня на debian периодически такая ситуация повторяется, грешу на сеть, возможно извечная проблема с dns, попробуй поставить локальный кеширующий dns сервер.
#8 12.01.2011 11:07
У нас есть сервер dns внутри сети.. я, кстати, в консоли вижу, что довольно часто астериск пытается "лукапить" айпишник моего прова, по которому регятся сип-транки, но я сомневаюсь, что это можно списать на причину "зависания" астериска

как я отписался, сделав sip show channels в момент падения астериска (т.е. юзверы не могли зарегестрироваться на астериске и в общем-то не проходили входящие и исходящих) я увидел около 5 каналов в состоянии bye. помогает ребут системы. ибо убив процессы астериска, после он не может запуститься %)
нашел на форуме похожую в чем-то проблему:
http://asteriskforum.ru/viewtopic.php?t= ... 0%B8%D0%BF

т.к. у меня включен модуль cdr для mysql, то пришел к выводу, что вполне вероятно он и вешает астериск со временем
попробую отключить, посмотрю что будет.
в добавок, я компилировал астериск с модулем res_config_mysql, но он не используется у меня.. не настраивал

Samael, у мя бывает и не раз в день, бывает и пару раз %)
перезагружать не проблема, но пользователям ооочень неприятно, когда вдруг вешается связь.
и вообще, как-то не по себе от мысли, что что-то там работает не так %)
#9 12.01.2011 12:21
у меня точно также ситуация происходит, но модуль cdr для mysql не установлен.
#10 12.01.2011 12:58
Наблюдал такую проблему на 1.6.2.12 и 13 + freepbx
Зависшие каналы появляются после трасфера
астер пытается терминировать звонки по rtptimeout -
chan_sip.c: Disconnecting call 'SIP/105-00000003' for lack of RTP activity in 61 seconds
но канал остается висеть, после количество зависших каналов лавинообразно нарастает и астер виснет
Нашел костыль - скриптом отслеживаю повисший канал и через 10 мин перезагружаю астер через kill -9
На 1.6.2.15 таких проблем пока не было
#11 12.01.2011 13:02
Меня тут как-то наталкивали на мысль, что это может быть проблема с памятью. Прогоните memtest. Может что покажет?
У меня просто пациент вешается, когда память забита метров на 700-800. Причем виснет интересно. Ядро еще как-то фурычит (судя по логам), половина демонов умирает, а астериск вообще часа за 2 до этого перестает логи писать. Но работает. Такое впечатление, что файлов открытых много. Но реально - тысячи 2 на всю систему.
_________________
Asterisk 1.4.30 @ Ubuntu 9.04 + Cisco MC3810 + NEC NEAX 2000IPS + Polycom IP Phones
#12 12.01.2011 13:05
Samael
память рабочая -проверено
#13 12.01.2011 13:34
andgre wrote:
Наблюдал такую проблему на 1.6.2.12 и 13 + freepbx
Зависшие каналы появляются после трасфера
астер пытается терминировать звонки по rtptimeout -
chan_sip.c: Disconnecting call 'SIP/105-00000003' for lack of RTP activity in 61 seconds
но канал остается висеть, после количество зависших каналов лавинообразно нарастает и астер виснет
Нашел костыль - скриптом отслеживаю повисший канал и через 10 мин перезагружаю астер через kill -9
На 1.6.2.15 таких проблем пока не было

в точку, такие жи симптомы. Но и на 1.6.2.15 тоже есть. Хотя еще хочу попробовать полностью удалить и переставить.
#14 12.01.2011 15:03
очень похоже на deadlock. запускай в дебаг режиме, а патом трейсь корки .
многие еще с 1,4 боятся слазить ,так как не совсем стабильны эти новые версии.
#15 12.01.2011 15:16
ZloMurz wrote:
у меня точно также ситуация происходит, но модуль cdr для mysql не установлен.

я пака что не утверждаю, что у меня именно из-за этого зависало.
предположил. сейчас отключил. сегодня и завтра ещё посмотрю, зависнет система или нет.

Samael wrote:
Меня тут как-то наталкивали на мысль, что это может быть проблема с памятью. Прогоните memtest. Может что покажет?
У меня просто пациент вешается, когда память забита метров на 700-800. Причем виснет интересно. Ядро еще как-то фурычит (судя по логам), половина демонов умирает, а астериск вообще часа за 2 до этого перестает логи писать. Но работает. Такое впечатление, что файлов открытых много. Но реально - тысячи 2 на всю систему.

ещё раз отпишусь, что до этого стоял астериск на centos и 3 месяца почти без особых проблем проработал. но там версия была 1.6.2 и без cdr на mysql
#16 13.01.2011 09:31
А проапдетить не судьба чтоли? Насколько помню в последнем предрелизе утечки памяти фиксили как раз. Также я в курсе падений версии 1.8.1 - тут только апдейт поможет.
_________________
Успехов!
#17 13.01.2011 18:17
у меня 1.8.1.1, куда уж там апдейтить))
правда в упор не помню, какую я ставил, патченую или нет.. на выходных попробую пропатчить, на всякий случай. посмотрю что и как там будет.
#18 15.01.2011 05:55
lsd25 wrote:
у меня 1.8.1.1, куда уж там апдейтить))

Shocked а что - посмотреть в верхний правый угол форума на актуальную версию - опять не судьба чтоли? Smile
На тот момент что я писал - была долгое время уже 1.8.2-rc1, на мой взгляд - первая стабильная версия в этой ветке, которая уже пригодна для продакшина. А сегодня вон и 1.8.2 вышла, прямо кстати как.
Повторяю для всех кто не услышал еще: все что было до 1.8.1-rc1 - не имеет смысла вообще даже обсуждать какието проблемы. Апдейтитесь, потом поговорим. Если проблемы еще останутся..
_________________
Успехов!
#19 16.01.2011 22:08
обновился до 1.8.2
результат один и тот же. так и зависают каналы..
#20 16.01.2011 22:40
ну тогда поздравляю, вы выявили у себя аномалию Smile давайте теперь дебажить будем и фиксить всем на радость

Added after 23 minutes:

Samael wrote:
Такое впечатление, что файлов открытых много. Но реально - тысячи 2 на всю систему.

ulimit -c unlimited
ulimit -n 32768
_________________
Успехов!
#21 17.01.2011 09:59
поставте munin или mrtg для снятия данных с системы.
обычно помогает определится в какую сторону капать.
тем более вы говорите что после астера виснет всё
#22 18.01.2011 05:21
я не говорил что виснет все
зависает астериск
#23 19.01.2011 01:36
Сталкивался с таким исключительно на Ubuntu server 10.04, сервера HP Proliant dl120g5, dl120g6
asterisk 1.6.2.9 - 1.6.2.13, 1.8
зависшие каналы:
Code:
172.29.254.12 328715 79c16b6f27c4517 0x8 (alaw) No Rx: BYE
192.168.150.5 0132 6ed67f610755158 0x8 (alaw) No Rx: BYE
172.29.254.12 4212326752 SBC24ce2a228e7d 0x8 (alaw) No Rx: ACK
172.29.254.12 4212419915 SBCa0678a52c9d9 0x8 (alaw) No Rx: ACK
172.29.254.12 4212483493 SBC5a7b821e6da1 0x8 (alaw) No Rx: ACK
192.168.150.5 0132 7f712a615bb319e 0x8 (alaw) No Rx: BYE
172.29.254.12 4212502845 SBC16f2ee02bd5f 0x8 (alaw) No Rx: ACK
192.168.150.5 0132 D1B9-A716-9900- 0x8 (alaw) No Rx: BYE
172.29.254.12 4212383055 SBC0780083bcfb9 0x8 (alaw) No Rx: ACK
172.29.254.12 4212545298 SBC9f4cc18d43ab 0x8 (alaw) No Rx: ACK
192.168.150.5 0132 D1B9-A716-30995 0x8 (alaw) No Rx: BYE
192.168.150.5 0135 D1B9-A716-9126- 0x8 (alaw) No Rx: BYE
172.29.254.12 4212326752 SBC1cef3c62d4fa 0x8 (alaw) No Rx: ACK
192.168.150.5 0128 372ac1647400b43 0x8 (alaw) No Rx: BYE
192.168.150.5 0132 5779fd734967b9e 0x8 (alaw) No Rx: BYE
172.29.254.12 4212489968 SBC3e66b0ae724d 0x8 (alaw) No Rx: ACK
172.29.254.12 4212483493 SBC725bc89d93c5 0x8 (alaw) No Rx: ACK
172.29.254.12 4212326752 SBC5b580077726e 0x8 (alaw) No Rx: ACK
192.168.150.5 0132 3efde769689a0b8 0x8 (alaw) No Rx: BYE
192.168.150.5 0130 189ca4ba40d7593 0x8 (alaw) No Rx: BYE

Перевел на Debian Lenny, uptime больше месяца в обоих случаях
#24 19.01.2011 12:40
попробывал поигрался я параметрами rtptimeout и rtpholdtimeout - бесполезно
один фиг залипают каналы и виснет астериск стабильно раз в сутки.
буду переезжать тогда.
#25 19.01.2011 13:47
ulimit делали?
_________________
Успехов!
#26 19.01.2011 14:04
у меня таже ботва на Debian squeeze.

с ulimit поигрался, не помогает. Тоже буду переезжать на Debian Lenny
#27 20.01.2011 00:10
imho, дело не в бобине.. тоесть не в операционке. в любом случае вон апдейты наконец пачками попёрли - что ни день то новые версии начали выходить, что не может не радовать. вобщем апдейтите сам астериск сперва, рекомендую собирать руками всё, также ставьте пакеты какие ему нужны сперва все, чтоб не было зависимостей.
вот что я ставлю на генту перед сборкой астериска:
Code:
gnutls iksemel pwlib openh323 newt libvorbis speex sox subversion ffmpeg

еще можно самостоятельно отдебажить и найти причину проблемы, (неужели не интересно?) я помогу если что, обращайтесь в личку.
_________________
Успехов!
#28 20.01.2011 02:36
У кого зависает * подобным образом, используете ли вы Ring Group или Follow Me созданные во Freepbx?
Один раз при зависании * сделал сперва рестарт апачу и после * нормально поднялся через /etc/init.d/asterisk restart
На тот момент не придал этому значения, а сейчас проверить негде
#29 20.01.2011 13:27
anest wrote:
imho, дело не в бобине.. тоесть не в операционке. в любом случае вон апдейты наконец пачками попёрли - что ни день то новые версии начали выходить, что не может не радовать. вобщем апдейтите сам астериск сперва, рекомендую собирать руками всё, также ставьте пакеты какие ему нужны сперва все, чтоб не было зависимостей.

возможно и не в ос.
собираю ручками.. с зависимостями все ок.

bayadr wrote:
У кого зависает * подобным образом, используете ли вы Ring Group или Follow Me созданные во Freepbx?
Один раз при зависании * сделал сперва рестарт апачу и после * нормально поднялся через /etc/init.d/asterisk restart
На тот момент не придал этому значения, а сейчас проверить негде

Ring Group использую. но использовал ещё на дистрибе готовом AsteriskNow
и там все ок было, не наблюдал таких проблем. 3 месяца машина работала стабильно.
только там версия астера была 1.6.2
#30 20.01.2011 22:32
ринг группы используют dialparties.agi на php
#31 26.01.2011 05:59
В общем в прошлую пятницу удалил asterisk, полностью. Скачал последний релиз 1.6.2.16.1, Add-Ons 1.6.2.3. Пока похожих проблем не наблюдаю.

Added after 52 minutes:

рано радовался, только что опять завис... придется наверное все-таки linux переставлять...
#32 26.01.2011 06:21
Попробуйте сперва php до 5.2 откатить
#33 26.01.2011 06:30
у меня php 5.1 было... решилось только переустановкой ОСи Sad
#34 26.01.2011 07:20
еще вроде новости, возникает только при использовании Blind Transfer, и насколько успел заметить, если перевод осуществляется на peer, который в данный момент не доступен.
Пока наказал людям пользоваться только Attended Transfer. Помониторим, будет ли повторяться.
#35 26.01.2011 10:29
вот аналогично. переустановил, обновил. все тоже.
в ближайшие выходные буду ставить на дебиан и тестировать.

а по поводу слепого перевода.. у меня перевод звонков используется одним человеком, в основном, и то он использует перевод с уведомлением.
при этом стабильность зависания разная, может повиснуть 3 раза за час, а может за 2 суток один раз.
#36 26.01.2011 15:47
Может поможет: у меня все случаи зависания канала происходят примерно 1 р в 2 недели
после blindxfer вызова пришедшего с аналоговой линии (Wildcard AEX800).
Завмсший канал - sip show channels:
10.104.1.5 102 39676ff0309ac05 0x4 (ulaw) No Rx: BYE
Причем команда channel request hangup не приводит к желаемым результатам.

астер 1.6.2.15
#37 01.02.2011 13:40
запретил transfer без уведомления, сказал пользоваться только трансфером с уведомлением, и проблема исчезла.
#38 03.02.2011 09:38
когда был на ubuntu server, у мя перевод звонков с уведомлением пользовали.. результат тот же - вис астериск.
вот, всетаки, переехал на debian lenny 5.0.8, поставил свежий астериск, и вот почти неделю работает, повисаний не было.
стабильно в целом
пользую все теже ринг группы в том числе.
#39 03.02.2011 18:52
я думаю ось здесь не причем:
у меня виснет
fedora13, ядро 2.6.34.6-47.fc13.i686
астер 1.6.2.15
компилил на gcc-4.4.4-10.fc13.i686
При зависании канала в full - на мой взгляд ничего необычного (Core debug is at least 15). если нужно выложу
на сервере:Wildcard AEX800, 2 huawei 1550
#40 04.02.2011 07:55
ну я и не доказываю, что ось тут виновата. просто не совсем понятно, почему в одной падает, а в другой нет.
была б возможность уделить времени больше и покопать причины, позанимался бы.. а так, нужно чтобы работало без каких-либо нареканий - вот и нет выхода, кроме того как поставить на другую ось, где, вроде бы, зависаний не замечено.
у самого стоит TDM410P на 4 fxo порта..
#41 15.06.2011 11:32
Не знаю насколько моя проблема схожа с этой, у меня проблема с открытыми udp портами, которые астериск почему-то не закрывает, за месяц уже накопилось более 1000 открытых портов, раньше он ребутился через некоторое время при достижении ограничения open files в 1024, после увеличения этого значения до 2048 пока работает, но это всего лишь отсрочка конца.

Подсчет делаю командой
Code:
ls /proc/`cat /var/run/asterisk/asterisk.pid`/fd | wc -w
это кол-во не совпадает с кол-ом
Code:
asterisk -rx "sip show channels" | wc -l
На данный момент значения 1281 и 410 соответственно.

Временное решение выгрузка chan_sip.so и его обратная загрузка.

Версия астериска 1.4.29.1 , что интересно данная проблема не на всех машинах. У меня имеется несколько серверов с разной версией ядра, так вот на некоторых серверах этой проблемы нет, пакеты компилировал сам, т.к на астериск наложены патчи. Из этого напрашивается вывод, что сама по себе версия стабильная, и видимо проблема прокралась при компилировании пакета, других вариантов пока не придумал.
#42 16.06.2011 08:17
Debian Squeezy, asterisk 1.6.2.18, тоже все виснуть стало.
Core show locks выдает
=== Thread ID: -160412816 (do_monitor started at [23162] chan_sip.c restart_monitor())
=== ---> Lock #0 (astobj2.c): MUTEX 164 ao2_lock &p->priv_data.lock 0xf693a008 (1)
/usr/sbin/asterisk(ast_bt_get_addresses+0x19) [0x810e7f9]
/usr/sbin/asterisk() [0x80872b8]
/usr/sbin/asterisk(ao2_lock+0x4c) [0x8087e49]
/usr/sbin/asterisk() [0x8088996]
/usr/sbin/asterisk(_ao2_callback+0x56) [0x8088d53]
/usr/lib/asterisk/modules/chan_sip.so(+0x64b6c) [0xf6d47b6c]
/usr/sbin/asterisk() [0x8185e3e]
/lib/i686/cmov/libpthread.so.0(+0x5955) [0xf7524955]
/lib/i686/cmov/libc.so.6(clone+0x5e) [0xf7732e7e]
=== ---> Tried and failed to get Lock #1 (chan_sip.c): MUTEX 23042 check_rtp_timeout (channel lock) 0xf610d4dc (0)
/usr/sbin/asterisk(ast_bt_get_addresses+0x19) [0x810e7f9]
/usr/sbin/asterisk() [0x80a1c4a]
/usr/sbin/asterisk(__ast_channel_trylock+0xa1) [0x80b48c2]
/usr/lib/asterisk/modules/chan_sip.so(+0x647e2) [0xf6d477e2]
/usr/lib/asterisk/modules/chan_sip.so(+0x42798) [0xf6d25798]
/usr/sbin/asterisk() [0x8088a60]
/usr/sbin/asterisk(_ao2_callback+0x56) [0x8088d53]
/usr/lib/asterisk/modules/chan_sip.so(+0x64b6c) [0xf6d47b6c]
/usr/sbin/asterisk() [0x8185e3e]
/lib/i686/cmov/libpthread.so.0(+0x5955) [0xf7524955]
/lib/i686/cmov/libc.so.6(clone+0x5e) [0xf7732e7e]
=== -------------------------------------------------------------------
===
=== Thread ID: -163021968 (pbx_thread started at [ 4630] pbx.c ast_pbx_start())
=== ---> Lock #0 (channel.c): MUTEX 2769 __ast_read (channel lock) 0xf610d4dc (1)
/usr/sbin/asterisk(ast_bt_get_addresses+0x19) [0x810e7f9]
/usr/sbin/asterisk() [0x80a1c4a]
/usr/sbin/asterisk(__ast_channel_trylock+0xa1) [0x80b48c2]
/usr/sbin/asterisk() [0x80a947b]
/usr/sbin/asterisk(ast_read+0x19) [0x80ab144]
/usr/lib/asterisk/modules/app_queue.so(+0xd223) [0xf70b4223]
/usr/lib/asterisk/modules/app_queue.so(+0xfab8) [0xf70b6ab8]
/usr/lib/asterisk/modules/app_queue.so(+0x15f91) [0xf70bcf91]
/usr/sbin/asterisk(pbx_exec+0x1a5) [0x8122464]
/usr/sbin/asterisk() [0x8129c86]
/usr/sbin/asterisk(ast_spawn_extension+0x53) [0x812b534]
/usr/sbin/asterisk() [0x812bc2d]
/usr/sbin/asterisk() [0x812d0f0]
/usr/sbin/asterisk() [0x8185e3e]
/lib/i686/cmov/libpthread.so.0(+0x5955) [0xf7524955]
/lib/i686/cmov/libc.so.6(clone+0x5e) [0xf7732e7e]

Машина
Code:

~# cat /proc/cpuinfo | grep 'model name'
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
model name : Intel(R) Xeon(R) CPU 5160 @ 3.00GHz
~# uname -a
Linux asterisk 2.6.32-5-amd64 #1 SMP Wed Jan 12 05:14:59 UTC 2011 x86_64 GNU/Linux
#43 16.06.2011 17:44
Вопрос всем выше отписавшимся, а ОС у вас 64 или 86 ?
Имел достаточно давно затык с астериском на 64 битном Дебиане, еще на ветке 1.4
Проявлялось в фантомных глюках которые периодически появлялись и пропадали, причем закономерности никак не мог найти, перепробовал все что мог, стал плохо спать и начал просыпаться в холодном поту )
Потом вдруг чегой-то решил посмотреть версию линукса тут-то и обнаружилась мина(систему не я ставил).

Хотя люди пишут что у них на 64-х битах все хорошо работает, я с тех пор не доверяю 64 битным платформам при работе с астериском, мне спокойный сон дороже ))
#44 17.06.2011 08:51
У меня был опыт работы на 64. Правда:
1. проц - Xeon
2. CentOS 5.4
3. * 1.4.23 (точно не помню).

Нагрузка в районе 4000 звонков в час. Единственное но - отключили MySQL-запись CDR на лету. Делали скриптом по расписанию.

Сбоев никаких.
_________________
P4 3.0 + 1Gb CentOS 5.5 Aster 1.8.5
Не люблю gui-сборки: натуральный продукт вкуснее.
#45 28.06.2011 17:38
Подтягиваюсь к списку страдающихих от Deadlock.
Установил на выходных Debian 6 (32 бит), Asterisk 1.6.1.18.1 (до этого был 1.8.4.3)
За день, три-четыре зависания, в точности как описаны в этом топике. В логах ничего. Обстоятельства зависания неопределенные.
Вот последний раз было так:
каждую минуту мониторю из консоли sip show channels, все нормально: появляются и исчезают каналы ACK, INVITE, REGISTER, BYE
1. Поступает звонок из DAHDI/5 на экстеншн 1000 (секретарь) через обычный Dial. (Cisco SPA508G + панель BLF)
2. 1000 берет трубку и через Attended Transfer (от Cisco) переводит на 1022. (Mitel5220)
3. 1000 удачно переведя звонок кладет трубку, но BLF 1000 продолжает гореть InUse
4. В этот момент другой экстеншн, 1028, заканчивает свой разговор и кладет трубку - его BLF 1028 на панели секретаря продолжает гореть.
5. 1022 заканчивает разговор и кладет трубку - его BLF 1022, также продолжает гореть
6. Выполняю в консоли sip show channels - видим все три канала в состоянии Rx: BYE
7. hangup request SIP/XXX - не убивается
8. Пытаюсь выгрузить unload chan_sip.so - Soft unload failed
9. /etc/init.d/asterisk stop - не останавливается
10. Ну вообщем, как обычно kill -9 asterisk_pid
11. После того как asterisk вновь запущен, приходится перегружать Cisco SPA508G со своими кнопками, так как они остаются гореть красным (InUse) и не возвращаются в нормальное состояние.

Как решили свою проблему участники топика ???
#46 05.07.2011 19:29
к теме про 64 и 32 разрядность
у мя 32 всегда линукса. пака нет необходимости в 64.
так что на это нет смысла списывать, пака..

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

навязывается интересность, может ли что-то не такое быть с системой логов в 6-й версии дебиана, или под убунтой той же 10.10, что астериску это "не нравится".
скажите, кто более компетентный в данном вопросе, возможно ли это

сейчас юзаю 5.0.8 дебиан
на 6-й пака чот нет желания перескакивать

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

или возможно это и связано с Attended Transfer. как-то странно его, может, астериск под теми версиями осей обрабатывает 0_о хз, я глубоко не капал, так что просто предполагаю.
у меня тоже активно используется перевод такой на 2-3 линиях. одним человеком.
#47 28.07.2011 13:21
В одном из issue на багтрекере попалось на глаза зависание астериска (deadlock'и). Советовали отключать res_timing_*.so всё кроме res_timing_dahdi.so (если dahdi собран). Воспользовался их советом - уже месяц без зависаний Smile
#48 29.07.2011 16:07
Спасибо добрый человек, раньше имел хорошую привычку включать только необходимые модули. те сервера которые были настроены по принципу клонирования олд скульных работают без проблем. те что с 0 периодически виснутSmile сравнил, на тех что висну
Code:
asterisk -rx "module show" | grep timing
res_timing_dahdi.so DAHDI Timing Interface 0
res_timing_timerfd.so Timerfd Timing Interface 1
res_timing_pthread.so pthread Timing Interface 0
#49 30.07.2011 21:15
just_user wrote:
В одном из issue на багтрекере попалось на глаза зависание астериска (deadlock'и). Советовали отключать res_timing_*.so всё кроме res_timing_dahdi.so (если dahdi собран). Воспользовался их советом - уже месяц без зависаний Smile


А можно вопрос чайника? Ввожу * в эксплуатацию в небольшой фирме. И не хочу иметь малоприятных зависаний. Как именно надо отключать указанные модули?
У меня сейчас такое:
Code:
# asterisk -rx "module show" | grep timing
res_timing_dahdi.so DAHDI Timing Interface 1
res_timing_pthread.so pthread Timing Interface 0

Это хорошо или плохо? С учетом того, что плат Digium у меня в проекте нет. И не будет. Тогда вроде вообще res_timing_dahdi.so не при делах? А если не при делах, то как быть с синхронизирующими сигналами? Или я на воду дую?
#50 20.08.2011 11:00
вроде как сейчас у астериска есть в ядре источник тайминга, и digium модули не нужны, но я по привычке ставлю, советую вам оставить только digium и все.

Added after 41 seconds:

отключать модули надо в modules.conf
#51 26.08.2011 08:34
симптомы те же.
Debian squeeze + asterisk 1.8.5.0 + freepbx 2.9. Обновлялся начиная с 1.8.1. Периодически зависал при релоаде через freePBX, в логах freepbx были ошибки php, была проблема с этим. Вышло обновление ядра freepbx, по первым впечатлениям проблема исчезла.
Вчера завис "просто так" без каких-либо действий. Отключил модули с таймингами по совету в этой ветки. Наблюдаю.
#52 16.09.2011 20:23
Так какие результаты наблюдения?
_________________
Успехов!
#53 26.09.2011 14:16
После обновления на 1.8.6 пропало зависание при релоаде из веб-интерфейса, часто что-то правим, полет нормальный. Работа в целом стабильна, после обновления аптайм практически месяц. Т.е. небыло ни одного сбоя.
#54 26.09.2011 14:23
just_user wrote:
В одном из issue на багтрекере попалось на глаза зависание астериска (deadlock'и). Советовали отключать res_timing_*.so всё кроме res_timing_dahdi.so (если dahdi собран). Воспользовался их советом - уже месяц без зависаний Smile

Не хочу "накаркать", но у меня тоже. Выгрузил все тайминги, оставил только dahdi. Пару месяцев - полет нормальный.
#55 10.11.2011 21:59
Также были проблемы с подвисанием. Система Debian Lenny + Asterisk 1.8.7.0.
Наблюдал за большой утечкой памяти в работе системы. За две недели uptime'а, 1 ГБайт оперативной памяти почти полностью "съедался".
Перекомпиляция Asterisk с разными ключами(в т.ч. с поддержкой Hoard Memory Allocator) ожидаемого результата не дала.
Проблема решилась со сбросом кэш-памяти Linux.
В crontab прописал такую строчку:
0 */1 * * * root /bin/sync; echo 3 > /proc/sys/vm/drop_caches

http://linux-mm.org/Drop_Caches
#56 10.11.2011 22:07
ну еще не факт что это именно у астериска память течёт. и сбрасывать кеш это костыль причём грубый.
лучше бы попробовали бы модули выгрузить как тут советовали.
_________________
Успехов!