Падает сервис WCS

Kirill · Apr 25, 2018

Ubuntu 16.04, wcs 5.0.3013
Периодически падает сервис WCS ( после обновления до последней версии ) . В логах сервера нет ошибок .

21:54:38,967 INFO ServerHandler - RTMP-pool-2-thread-3 sending bytes read ack after: 6775231361
21:54:39,549 INFO ServerHandler - RTMP-pool-2-thread-4 sending bytes read ack after: 13246408654
21:54:43,885 INFO ServerHandler - RTMP-pool-2-thread-1 sending bytes read ack after: 11476151234
21:54:47,577 INFO ServerHandler - RTMP-pool-2-thread-4 sending bytes read ack after: 13249059044
21:54:49,107 INFO ServerHandler - RTMP-pool-2-thread-2 sending bytes read ack after: 10000011703
21:54:52,658 INFO ServerHandler - RTMP-pool-2-thread-1 sending bytes read ack after: 11478718691
21:54:53,964 INFO ServerHandler - RTMP-pool-2-thread-3 sending bytes read ack after: 6777745065
21:54:55,535 INFO ServerHandler - RTMP-pool-2-thread-4 sending bytes read ack after: 13251600880
21:55:01,555 INFO ServerHandler - RTMP-pool-2-thread-2 sending bytes read ack after: 10002511902
21:55:01,792 INFO ServerHandler - RTMP-pool-2-thread-1 sending bytes read ack after: 11481222151
21:55:03,566 INFO ServerHandler - RTMP-pool-2-thread-4 sending bytes read ack after: 13254284463
21:55:08,949 INFO ServerHandler - RTMP-pool-2-thread-3 sending bytes read ack after: 6780258957
21:55:10,680 INFO ServerHandler - RTMP-pool-2-thread-1 sending bytes read ack after: 11483773410
21:55:11,584 INFO ServerHandler - RTMP-pool-2-thread-4 sending bytes read ack after: 13256852758
21:55:14,041 INFO ServerHandler - RTMP-pool-2-thread-2 sending bytes read ack after: 10005014567
21:55:16,447 INFO ShutdownHandler - Thread-12 Shutting down WebSocket connections
21:55:16,447 INFO ativeShutdownHandler - Thread-6 Shutting down native libs
21:55:16,448 INFO ativeShutdownHandler - Thread-6 Done
21:55:16,448 INFO ShutdownHandler - Thread-11 Shutting down WebSocket connections
21:55:16,448 INFO ShutdownHandler - Thread-13 Shutting down Rtsp sessions
21:55:16,448 INFO ShutdownHandler - Thread-7 Shutting down RTMP Connections
21:55:16,448 INFO ShutdownHandler - Thread-7 RTMP connections closed
21:55:16,448 INFO ShutdownHandler - Thread-10 Shutting down RTMFP Connections
21:55:16,449 INFO Sessions - Thread-10 shutdown
21:55:16,449 INFO ShutdownHandler - Thread-10 RTMFP connections closed
21:55:16,456 INFO ShutdownHandler - Thread-11 WebSocket connections closed
21:55:16,456 INFO ShutdownHandler - Thread-12 WebSocket connections closed
21:55:16,458 INFO WCS4Handler - DISCONNECT-CLIENT-pool-24-thread-32 Disconnect client: com.flashphoner.server.client.MediaWCSClient@7e9da675
21:55:16,459 INFO WCS4Handler - DISCONNECT-CLIENT-pool-24-thread-32.
[-- BEGIN CLIENT LOG --]
CONF: ClientConfig{rtspMedia=false, wsTunnel=false, login='6h8e15hkcar0fd3guirmhu0uj2', authenticationName='null', password='null', domain='null', outboundProxy='null', localPort=-1, port=0, visibleName='null', regRequired=false, applicat
IMPL: WSClient{channel=[id: 0x30740746, /123.123.123.123:31644 :> /192.168.0.4:8443], handler=com.flashphoner.server.client.handler.DelegateHandler@4798f8c0, closed=false, pageUrl='null', countUnansweredPing=0}
LOGS:
Client didn't pushed logs to server, try to enable push_log at client side.
[-- END CLIENT LOG ----]
21:55:16,459 INFO WCS4Handler - DISCONNECT-CLIENT-pool-24-thread-32 Report client-6h8e15hkcar0fd3guirmhu0uj2-2018.04.24.21.55.16-1524606916459.report is submitted
21:55:16,497 INFO ShutdownHandler - Thread-13 Rtsp sessions closed

Какие логи и конфигурация вам нужна для анализа проблемы ?

Max · Apr 25, 2018

Добрый день.
Сначала нужно разобраться что значит падает.
1. Что показывают процессы?
ps aux | grep Flashphoner
должно быть два процесса
если один, то сервер скрэшился, т.е. процесс ядра вышел в результате ошибки
2. Сколько на момент падения было занято памяти?
Всего занятой.
Всего свободной.
RSS процесса.
3. Есть ли в папке WCS_HOME/logs крэшлоги
error12345.log
где 12345 - ID процесса, который упал.
4. Есть ли в логах /var/log/messages сообщения о проблемах с памятью.

Max · Apr 25, 2018

Собрать нужно следующее:

1. WCS_HOME/logs/server_logs/flashphoner.log
2. WCS_HOME/logs/server_logs/flashphoner_manager.log
3. WCS_HOME/logs/errorXXXX.log
4. WCS_HOME/logs/gc-core.log
5. WCS_HOME/logs/gc-manager.log
6. WCS_HOME/logs/license.log
6. WCS_HOME/conf
7. /var/log/messages
8. top (снимки процессов и памяти)

Логи можно выслать на logs@flashphoner.com. Убедитесь, что логи отражают момент крэша.
Из-за почасовой ротации, в новом часу могут появиться пустые логи в которых еще ничего не записалось.

Max · Apr 25, 2018

Как именно проходит стриминг в вашем случае? Откуда куда?

Kirill · Apr 25, 2018

Max said:
Добрый день.
Сначала нужно разобраться что значит падает.
1. Что показывают процессы?
ps aux | grep Flashphoner
должно быть два процесса
если один, то сервер скрэшился, т.е. процесс ядра вышел в результате ошибки
2. Сколько на момент падения было занято памяти?
Всего занятой.
Всего свободной.
RSS процесса.
3. Есть ли в папке WCS_HOME/logs крэшлоги
error12345.log
где 12345 - ID процесса, который упал.
4. Есть ли в логах /var/log/messages сообщения о проблемах с памятью.

1. Сервис уже рестартанул , будем ждать следующего падения. Но , когда смотрел /etc/init.d/webcallserver status , был - running.
2. Будем ждать следующего падения
3. Нету, не наблюдал ни разу.

Kirill · Apr 25, 2018

Max said:
Как именно проходит стриминг в вашем случае? Откуда куда?

ffmpeg берет поток с ip камер, отправляет его на wcs . C wcs поток (WebRTC) клиенты получают по запросу.

Kirill · Apr 25, 2018

Max said:
Добрый день.
Сначала нужно разобраться что значит падает.

Панель управления не активна , потоки не отправляются на сервер. При этом статус сервиса - пишет запущен.

Max said:
Собрать нужно следующее:

1. WCS_HOME/logs/server_logs/flashphoner.log
2. WCS_HOME/logs/server_logs/flashphoner_manager.log
3. WCS_HOME/logs/errorXXXX.log
4. WCS_HOME/logs/gc-core.log
5. WCS_HOME/logs/gc-manager.log
6. WCS_HOME/logs/license.log
6. WCS_HOME/conf
7. /var/log/messages
8. top (снимки процессов и памяти)

Логи можно выслать на logs@flashphoner.com. Убедитесь, что логи отражают момент крэша.
Из-за почасовой ротации, в новом часу могут появиться пустые логи в которых еще ничего не записалось.

Отправлено.

Max · Apr 25, 2018

1. Убедитесь что вы не вызываете перезагрузку серверного процесса через CLI или другими способами.
2. Проверьте, имеет ли ваш сервер коннект к серверу лицензий
Запрос должен возвращать XML:

Code:

curl -k https://my.flashphoner.com/keep_alive.action

Code:

<?xml version="1.0" encoding="UTF-8"?><Data><code>11223766</code></Data>

Если возвращает, попробуйте закомментировать настройки прокси в конфиге wcs-core.properties и перезапустить WCS.
Т.е. возобновить прямой коннект к лиц. серверам.
3. Попробуйте обновить JDK до последней 1.8.x с сайта Oracle.com
Инструкция здесь:
https://flashphoner.com/docs/wcs5/w...eparing_for_installation-jdk_installation.htm

Для дальнейшего разбора нужен SSH доступ чтобы поснимать дампы более подробно и увидеть из-за чего завершается процесс ядра.

Kirill · Apr 26, 2018

Max said:
Добрый день.
Сначала нужно разобраться что значит падает.
1. Что показывают процессы?
ps aux | grep Flashphoner
должно быть два процесса
если один, то сервер скрэшился, т.е. процесс ядра вышел в результате ошибки

Code:

 # ps aux | grep Flashphoner
root     30897  0.0  0.0  14164   932 pts/1    S+   11:11   0:00 grep --color=auto Flashphoner

Проблема повторилась , предоставьте пожалуйста ключ(в личку или на почту) для доступа по ssh ( я его добавлю на сервер с wcs ).

Max · Apr 26, 2018

Пришлите пожалуйста приватный ключ на почту.
Публичные ключи мы не генерируем. Так быстрее.
logs@flashphoner.com

Max · Apr 30, 2018

Добрый день.

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

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

Kirill · May 7, 2018

Проблема осталась , вопрос все еще актуален.

Kirill · May 8, 2018

Нашел интересный момент.
Во время падения wcs срабатывает в кроне certbot, завершается с ошибкой ( т.к. порт занят другим приложением ) . Отключил автообновление сертификата.
Как связан certbot с работой WCS, на время обновления бота wcs выключается ( и после успешного обновления должен стартовать ) ? Это так и задумано ?

Max · May 8, 2018

certbot не должен быть никак связан с WCS
Он обычно делает свою работу и складывает файлы в папку /etc/letsencrypt
Другое дело, если дальше начинают работать скрипты, которые например импортируют эти сертификаты в WCS и перезагружают ядро, например через CLI.
Поэтому нужно разобраться что именно делает certbot и сопутствующие скрипты. Возможно они и делают restart.

Kirill · May 8, 2018

в кроне такой таск

Code:

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

Kirill · May 10, 2018

Нашел проблему, трабл был действительно связан с certbot. Проблема была с тем, что прехук выключал WCS, далее cerbot завершался с ошибкой и возобновление не произошло, т.к. постхук видимо должен отработать после успешного завершения работы.
Возможно будет кому-то полезно ....

Падает сервис WCS

Kirill

Member

Max

Administrator

Max

Administrator

Max

Administrator

Kirill

Member

Kirill

Member

Kirill

Member

Max

Administrator

Kirill

Member

Max

Administrator

Max

Administrator

Kirill

Member

Kirill

Member

Max

Administrator

Kirill

Member

Kirill

Member