Перестали обновлятся клиенты в сети. В логах загадочная ошибка 2
Отправлено 28 Февраль 2018 - 15:01
Перестали обновлятся клиенты в сети. В логах загадочная ошибка 2
Отправлено 28 Февраль 2018 - 15:49
Ну, по этому отрывку можно только увидеть, что хэш файла отличается от того хэша, который сообщил агенту сервер.
20180228 14:49:21 [INF] [ Loader ] Download file 90/sysinfo/9/revision.xml from C:/ProgramData/Doctor Web/Updater/TempES/90/sysinfo/9/revision.xml to C:/PROGRA~3/DOCTOR~1/Updater/repo/90/sysinfo/9/20180227135547.xml
20180228 14:49:21 [ERR] [ Loader ] file 20180227135547.xml (90/sysinfo/9/revision.xml) downloaded but has wrong hash!
20180228 14:49:21 [ERR] [ Loader ] 90/sysinfo/9/revision.xml hash in XML = 147a592fdceec920c8388e04da57325c39b6a6666218b6301dfa4799f3a1f392 file hash = 2da91c6051d629c7074790ca1800cfa49576f9551fbc9f4f978b92fb3003e8e4
Нужен, как минимум, дебажный лог сервиса (dwservice.log) ну и dwupdater.log бы целиком. Если опасаетесь за приватность, можно в личку. Или через саппорт.
Отправлено 28 Февраль 2018 - 16:47
Да с хешем и так понятно. От чего это вдруг?
Может как-то сбросить?
Хеш файл чего?
Подскажите что генерит dwervice.log?
Сообщение было изменено SiE: 28 Февраль 2018 - 16:47
Отправлено 28 Февраль 2018 - 17:25
>> От чего это вдруг?
Для этого и прошу логи.
>> Может как-то сбросить?
Вполне. Для этого и прошу логи.
>> Хеш файл чего?
А говорили "Да с хешем и так понятно".
Не хеш файл, а хеш файла. Имя которого фигурирует в цитате.
Когда сервер передает агенту какой-то файл, он сообщает его хэш. Агент записывает этот файл в кэш, в качестве имени используя принятый хэш файла. А потом подсчитав хэш принятого файла сравнивает с тем, что ему сообщил сервер.
Кто не прав и на каком этапе -- могут помочь прояснить логи.
>> Подскажите что генерит dwervice.log?
Лог сервиса Агента.
Отправлено 28 Февраль 2018 - 18:11
Продублирую оба лога. чтобы ровненько по времени.
Отправлено 01 Март 2018 - 11:58
Да, спасибо, похоже ничего нового и я как-то упустил из виду важную деталь -- вы говорите, что ошибка обновления нв всех машинах сети.
Эта состояние сохраняется, по-прежнему, на всех машинах?
Тогда я должен был сразу попросить вас лог сервера, конечно же.
/var/opt/drwcs/log/drwcsd.log + drwcsd.NN.log.gz, если есть.
Сообщение было изменено Kirill Polubelov: 01 Март 2018 - 11:59
Отправлено 01 Март 2018 - 14:47
Вот они.
Надеюсь это что-то прояснит.
Отправлено 01 Март 2018 - 16:12
У вас же есть доступ к консоли (по ssh или напрямую) к серверу?
Выполните, пожалуйста, команду
pgrep drwcs
Отправлено 01 Март 2018 - 16:19
1227 в ответ.
Отправлено 01 Март 2018 - 16:25
>> Репозиторий на сервере презагружали. Сервер перезагружали.
А когда вы перезагружали Сервер и как?
Сообщение было изменено Kirill Polubelov: 01 Март 2018 - 16:25
Отправлено 01 Март 2018 - 16:44
Все случилось 26го.
перезагружали 27го. Через веб интерфейс.
Репозиторий через состояние репозитория обновляли.
Через конфигурацию репозитория сохранить и повторно синхронизировать делали.
Отправлено 01 Март 2018 - 16:45
Где-то в районе, начиная, как минимум с 27 числа, сервер работал, похоже, в два смычка, что косвенно подтверждается записями вида (drwcsd.7.log):
20180227.183414.46 tr2 [01189 01275] wrk:5 [Update] tcp://192.168.0.5:57627/st: Product "20-drwagent" is in pending state
20180227.183936.55 inf [00951 00951] main [Logger] Logfile has been opened by Dr.Web Server Version REL-1000 Build 10.01.0.201705110
20180227.183936.58 inf [00952 00952] main [Logger] Logfile has been opened by Dr.Web Server Version REL-1000 Build 10.01.0.201705110
20180227.183936.60 tr0 [01188 01191] sig:1 [Signal] Creating pid file "/var/opt/drwcs/run/drwcs.pid"
20180227.183936.60 tr0 [01187 01192] sig:1 [Signal] Creating pid file "/var/opt/drwcs/run/drwcs.pid"
20180227.183936.62 wrn [01188 01191] sig:1 Stalled PID file "/var/opt/drwcs/run/drwcs.pid" will be overwritten
20180227.183936.62 wrn [01187 01192] sig:1 Stalled PID file "/var/opt/drwcs/run/drwcs.pid" will be overwritten
...
20180227.183937.51 ERR [01188 01294] net:1 [FrontDoor] Unable to create command frontdoor secure socket "tcp://127.0.0.1:10101" because of
20180227.183937.51 ERR [01188 01294] net:1 unable to bind socket to "127.0.0.1:10101" because of
20180227.183937.51 ERR [01188 01294] net:1 Address already in use
20180227.183937.54 ERR [01188 01294] net:1 [FrontDoor] No frontdoor sockets have been created
...
20180227.183937.89 inf [01188 01193] str:1 Dr.Web Server Version 10.01.0.201705110 (REL-1000, Linux/x64) has risen
20180227.183937.89 tr0 [01187 01187] main [Server] Started well after 01.239
20180227.183937.89 tr0 [01188 01188] main [Server] Started well after 01.262
20180227.183937.92 ntc [01187 01296] wrk:1 [SqLite3] DB engine version 3.8.10.2 (compiled for 3.8.10.2)
20180227.183937.92 ntc [01188 01289] wrk:1 [SqLite3] DB engine version 3.8.10.2 (compiled for 3.8.10.2)
20180227.183937.94 inf [01187 01296] wrk:1 [SqLite3/0] Database is 222162944 bytes long and found in "/var/opt/drwcs/database.sqlite"
20180227.183937.94 inf [01188 01289] wrk:1 [SqLite3/0] Database is 222162944 bytes long and found in "/var/opt/drwcs/database.sqlite"
20180227.183938.50 tr1 [01187 01296] wrk:1 [SqLite3/0] Created instance #0x00007FB7D8003B18 @0x00007FB7D8001030
20180227.183938.50 tr1 [01187 01296] wrk:1 [SqLite3/1] Created instance #0x00007FB7D8003678 @0x00007FB7D8003F70
20180227.183938.50 tr0 [01187 01296] wrk:1 [Server] Database "SQLite3" V3.8
20180227.183938.50 tr1 [01188 01289] wrk:1 [SqLite3/0] Created instance #0x00007F0E90000B98 @0x00007F0E90001030
20180227.183938.50 tr1 [01188 01289] wrk:1 [SqLite3/1] Created instance #0x00007F0E90003678 @0x00007F0E9005B510
...
20180227.183938.57 tr1 [01188 01289] wrk:1 [DbMgr] Verify last exit ...
20180227.183938.57 tr2 [01188 01289] wrk:1 [DbMgr] Database was not closed last time
20180227.183938.57 tr2 [01188 01289] wrk:1 [DbMgr] Updating links status to offline ...
20180227.183938.57 tr2 [01188 01289] wrk:1 [DbMgr] Logging out our stations ...
20180227.183938.57 tr1 [01187 01296] wrk:1 Dr.Web Server DB Management Library Version 10.01.0.201705110 (REL-1000, Linux/x64)
20180227.183938.57 tr1 [01187 01296] wrk:1 [DbMgr] Startup database verification ...
20180227.183938.57 tr1 [01187 01296] wrk:1 [DbMgr] Version verification ...
20180227.183938.57 tr3 [01187 01296] wrk:1 [DbMgr] Database version is 228
20180227.183938.57 tr1 [01187 01296] wrk:1 [DbMgr] Verify last exit ...
20180227.183938.57 tr2 [01187 01296] wrk:1 [DbMgr] Database was not closed last time
20180227.183938.57 tr2 [01187 01296] wrk:1 [DbMgr] Updating links status to offline ...
20180227.183938.57 ERR [01187 01296] wrk:1 [DB] Failed, database is locked, 00.000, UPDATE servers SET value=? WHERE name=? AND osid=? ["n", "conn", "9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28"]
20180227.183938.57 FTL [01187 01296] wrk:1 [DbMgr] Database verification failed, 00:00:00.000
20180227.183938.57 FTL [01187 01296] wrk:1 [Server] Database is inconsistent, terminating
20180227.183938.57 wrn [01187 01296] wrk:1 [DB] Destroying instance "unnamed" in transaction state, rolling back
20180227.183938.57 ntc [01187 01296] wrk:1 [SqLite3/1] Statement cache: 0 hits, 1 missed, maximum 1K memory used (1 item, 1K now)
20180227.183938.57 ntc [01187 01296] wrk:1 [SqLite3/1] 1522 bytes, 1 hit "ROLLBACK"
28-го числа есть что-то похожее на попытку рестарта (drwcsd.6.log):
20180228.094202.74 tr2 [01188 01292] wrk:4 [Update] tcp://192.168.1.47:49497/st: Product "20-drwagent" is in pending state
20180228.094809.02 inf [00937 00937] main [Logger] Logfile has been opened by Dr.Web Server Version REL-1000 Build 10.01.0.201705110
20180228.094809.04 inf [00936 00936] main [Logger] Logfile has been opened by Dr.Web Server Version REL-1000 Build 10.01.0.201705110
20180228.094809.10 tr0 [01227 01229] sig:1 [Signal] Creating pid file "/var/opt/drwcs/run/drwcs.pid"
20180228.094809.10 tr3 [01227 01229] sig:1 Created PID file "/var/opt/drwcs/run/drwcs.pid"
20180228.094809.10 tr0 [01225 01230] sig:1 [Signal] Creating pid file "/var/opt/drwcs/run/drwcs.pid"
20180228.094809.10 FTL [01225 01230] sig:1 Found PID file "/var/opt/drwcs/run/drwcs.pid" and process with PID 1227 exists, abort loading
20180228.094809.10 tr0 [01225 01225] main [Signal processor] Total 1 job processed
20180228.094809.10 ntc [01225 01225] main [Server] Process exit code is 0x9/9 (unable to create PID file)
20180228.094809.12 inf [01227 01231] str:1 [Linux] Allocation mapping is left unchanged
20180228.094809.12 tr0 [01227 01231] str:1 Dr.Web Server Version 10.01.0.201705110 (REL-1000, Linux/x64) is rising
Судя по тому, что pid остался прежний, рестарта, как такового, не произошло.
Настораживает, также, тот факт, что что процедуры завершения, до Logfile has been opened не видно, как-будто сервер перед этим просто упал.
Надо бы ещё core файлы поискать.
Но, в любом случае, есть смысл рестартовать сервер.
Отправлено 01 Март 2018 - 16:55
Давайте-ка, сделаем так. Из консоли, под рутом:
/etc/init.d/drwcsd stop pgrep drwcs
команда не должна вернуть никакого номера.
Далее:
/etc/init.d/drwcsd syncrepository /etc/init.d/drwcsd start
После, надо подождать некоторое время (может в районе получаса), понаблюдать, как агенты себя почувствуют.
Сообщение было изменено Kirill Polubelov: 01 Март 2018 - 16:56
Отправлено 01 Март 2018 - 17:23
сделали. pid другой. один.
снова посыпались ошибки.
upd. ошибки массовые.
Сообщение было изменено SiE: 01 Март 2018 - 17:24
Отправлено 01 Март 2018 - 17:32
Сервер крутится на кластере виртуальных машин hyper-v. Рестартов и неожиданных закрытий не наблюдалось.
Может есть способ вычистить базу данных модулей и вирусных баз и снова ее наполнить? или дело не в этом?
Отправлено 01 Март 2018 - 18:03
Да, то, что на Hyper-V это видно из лога.
Явно, что-то залипло. Пока не очень ясно что и где.
Сделаем тогда вот что:
Проверьте, нет ли в /var/opt/drwcs/ каталога coredump?
В /var/opt/drwcs/etc/local.conf измените или добавьте следующие строки:
DRWCS_LEV=ALL # Задаст максимальный уровень логгирования. По окончании процедур диагностики, строку можно или удалить или заменить ALL на TRACE3
DRWCS_ROT=10,100M # Задаст режим ротирования логов -- хранить 10 файлов, макс. размер текущего лога 100 мегабайт. По окончании диагностики можно оставить так.
Выполните
/etc/init.d/drwcsd restart
Через некоторое время, когда в сети появится хотя бы одна проблемная станция, лог можно забирать.
Отправлено 01 Март 2018 - 18:28
Я так понял что лог drwcsd нужен?
И у меня рука дрогнула. Я в мобильном приложении в окне Ошибки обновления случайно сделал выделить все и удалить.
Там будет много лишнего в логе видимо.
Отправлено 01 Март 2018 - 18:47
Хм, а попробуйте-ка, временно, в целях диагностики, отключить приём АПО:
Веб-интерфейс:
Администрирование -> Конфигурация Сервера Dr.Web -> Статистика -> [ ] Состав оборудования и программ
Только рестарт не через веб-интерфейс, после этого, а:
/etc/init.d/drwcsd restart
Сообщение было изменено Kirill Polubelov: 01 Март 2018 - 18:48
Отправлено 01 Март 2018 - 19:12
отключил. Перезагрузил.
так же на sysinfo meta ругается.
Сообщение было изменено SiE: 01 Март 2018 - 19:15
Отправлено 01 Март 2018 - 19:36
Давайте, тогда, на одной из проблемных станций, проведём эксперимент, что называется, в лоб )
1. Дайте право станции на отключение самозащиты
2. Отключите самозащиту на станции
3. Из под администратора удалите C:/PROGRA~3/DOCTOR~1/Updater/repo/90/sysinfo/revisions.xml
Можно, даже, весь C:/PROGRA~3/DOCTOR~1/Updater/repo/90/sysinfo
4. Включите самозащиту
5. Дайте команду, из веб-фейса, на обновление компонентов для этой станции. Вижу, что ранее, вы это уже делали, значит умеете )
Сообщение было изменено Kirill Polubelov: 01 Март 2018 - 19:36
0 пользователей, 0 гостей, 0 скрытых