Итак:
1. Астер всегда запускал просто и без параметров:
Код: Выделить всё
root@sag:/home/none# /usr/sbin/asteriskКод: Выделить всё
root@sag:/home/none# ps waux | grep asterisk
root 1463 0.0 10.6 740920 219500 ? Ssl May29 0:52 /usr/sbin/asterisk4. Смотрю на процессы:
Вхожу в консоль, стопаю астер - команда проходит, и на этом всё, а именно: процесс не останавливается, с консоли не вываливаюсь в shell... Опа! Машина тупит, так по ssh ничего и не смог сделать.
5. Иду на клаву, пытаюсь остановить Астер в другом сеане - хрена с два. Ребутаюсь... Всё восстановилось (см. п.2).
Почитал сабж на английском.
Решил перевести. Возможно корявенько, но хоть что-то прояснилось...
Хотя, я так и не понял, как же (в пошаговом режиме мож кто в курсе) выйти именно корректно из сложившейся ситуации? Может у кого-то были похожие моменты?
На русских ресурсах (в живых обсуждениях и толксах) ничего не нашёл.
"Что такое Astcanary?"
В основном, это небольшое приложение, которое гарантирует, что в Asterisk нет потоков, которые «текут», и вызывают «загруженность» процессора, и превращает Asterisk-машину, в такую, что не отвечает на запросы.
Это работает так: создаётся файл, когда Asterisk выполняется с приоритетом реального времени (-р). Этот файл должен существовать, и astcanary-процессу должна быть предоставлена возможность продолжать работать, иначе сам Asterisk процесс, в течение короткого периода времени, замедлится сам до регулярного приоритета.
Технические характеристики:
Техническое объяснение в работе этого файла, предполагает следующее: предоставлять гарантии Asterisk, что нет потоков, которые «текут», и вызывают «загруженность» процессора, и превращает Asterisk-машину, в такую, что не отвечает на запросы.
Когда это произойдет («текучка» и «загруженность»), astcanary-процесс будет не в состоянии обновить метки на этот файл, и Asterisk заметит это в течение 120 секунд и отреагирует. Замедление процесса Asterisk до регулярного приоритета позволит администратору вмешаться, тем самым избегая необходимости перезагрузки всей машины.
Откуда же эта идея произошла?
В свое время, канарейки были проведены вместе с шахтерами вниз (в шахту). Их целью было предупредить шахтеров, когда они пробуривались в «газовый метановый карман» или место с другим накоплением вредного вещества. Канарейка, как наиболее чувствительное животное, немедленно падала (задыхались, наглотавшись газа). Видя это, горняки могли бы принять меры, чтобы избежать такую шахту (или как следствие, взрыва метана), видя неминуемую опасность.
Этот же процесс в Астериске служит для той же цели, хотя приоритетом реального времени является причина. Когда поток начинает «убегать с процессором», то, как правило, трудно сказать, какой поток вызвал проблемы, так как машина действует так, будто он «залочен» (на самом же деле, произошло то, что Asterisk работает на более высоком приоритете, чем даже оболочка (shell), так что такая «текучка» нитей процесса занимает все доступное время процессора.
Если это произойдет, то «astcanary-процесс» прекратится, чтобы получить любое процессорное, время, которое мы можем наблюдать с помощью реального времени поток в Asterisk. Если это произойдет, то система мониторинга потока может принять незамедлительные меры замедлить Asterisk до регулярного приоритета, таким образом позволяя администратору входить в систему и перезапустить Asterisk или, возможно, сделать еще один набор действий (таких, как получение обратной трассировки, чтобы разработчики знали, что именно пошло не так).
Обратите внимание, что в соответствии с POSIX.1, все потоки в одном процессе должны иметь один и тот же приоритет, поэтому, когда при мониторинге потоков системой Linux, они (потоки) «исключаются» из числа приоритетов процесса, порождающего эти потоки в этот же момент времени.
Вот почему эта «канарейка» должна существовать как совершенно отдельный процесс, а не просто как нить (поток) в самом Asterisk'е .
