точно. 9 ку забыл.
Перестали обновляться клиенты Ошибка 2.
#41
Отправлено 01 Март 2018 - 21:09
#42
Отправлено 01 Март 2018 - 21:13
Ну вот, мы почти у цели, еле-еле )
xxd revision.xml
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
...
Надо проверить диск.
Сообщение было изменено Kirill Polubelov: 01 Март 2018 - 21:15
#43
Отправлено 01 Март 2018 - 21:20
Диск? Всмысле виртуальный?
#44
Отправлено 01 Март 2018 - 21:26
если бы масиив бажил то другие 15 виртуалок бы об этом сказали бы.
Видимо на логические ошибки имеется ввиду?
#45
Отправлено 01 Март 2018 - 21:29
Файл, как видите, представляет из себя набор 0x00
Хотя, настоящий revision.xml из этой ревизии выглядит примерно так:
cat /var/opt/drwcs/repository/20-drwagent/20180227135547/90/sysinfo/9/revision.xml
<?xml version="1.0" encoding="UTF-8"?>
<revision>
<file hash="4b3117018bd8cc50de0a9cabd4cb3a56ea94d5959cfd4cba5aeb65cca567dafb" name="common/dwsysinfo.exe" optional="no" size="12623912">
<lzma hash="80dae75018185179729b0d5b2faa9a52411806cf735bcffc20777b67b29cd73f" name="common/dwsysinfo.exe.lzma" size="12448532"/>
</file>
<file hash="7e542b2ec0e7788d626292a43ec503860138a18084bf87d538e12267ace7dd41" name="script.lua" optional="no" size="494">
<lzma hash="f54b37dfbcdae9d375f1f7b19adabe0a4ae9217a8e3a5bbf02217e471383bfbf" name="script.lua.lzma" size="297"/>
</file>
<file hash="4b9da292a2ed715cdaf54941f3c621227ab74e81b4fc7041fd1acb40970af3d6" name="x64/win/nt/common/dwsysinfo.dll" optional="no" size="739944">
<lzma hash="ebe27bc046c69118ea1db4377347c7eb289380fe217eb3b9655dfb8d1d0405ab" name="x64/win/nt/common/dwsysinfo.dll.lzma" size="267970"/>
</file>
<file hash="ffdce35e9fd746495939a8edc40c8fb87d360a5deb13402f0922bb1d0c4b90fd" name="x86/win/nt/common/dwsysinfo.dll" optional="no" size="604840">
<lzma hash="17d3f904f7f91940b49fc760ce5ebaf7dd20e38deada44f8098c80bbdbffde4a" name="x86/win/nt/common/dwsysinfo.dll.lzma" size="235945"/>
</file>
<sign value="492933D6EC6B852904C838B06CE9B04E1C641D537696E57AAF8ACDFCABE2358157E2D6A1681C201502031EE4B4A11318DBE7C1B9ECE0CAF5D40207FB38C7D203"/>
</revision>
#46
Отправлено 01 Март 2018 - 21:30
так. Подключился я напрямую к виртуальной машине. Вижу такую надпись: [124554.099449] blk_update_request: I/O error, dev fd0, sector 0
я так понимаю в этом дело?
При этом в консоль (считайте напрямую на сервере) лог дебага шел
Что странно, удаленно на "бэды" проверка прошла с 0 ошибками.
Я так понимаю ее нужно передернуть?
Сообщение было изменено SiE: 01 Март 2018 - 21:31
#48
Отправлено 01 Март 2018 - 21:37
И причем здесь флоппи? 0_о
#49
Отправлено 01 Март 2018 - 21:42
DrWeb сервер не может обращаться к флоппи же? ))
#50
Отправлено 01 Март 2018 - 21:43
Нет, флоппи здесь не причём. Давайте отложим на подумать до завтра )
Есть, конечно, простой вариант, грохнуть этих ревизий и получить их с ВСО по новой. Но как бы понять, отчего так произошло.
#51
Отправлено 01 Март 2018 - 21:44
давайте. Собственно я его перезапустил из управления Гипер-В пока ошибки этой нет. Но ревизия в нулях. Почитаю еще сам по поводу странного флоппи на виртуальной CentOS ....
#52
Отправлено 02 Март 2018 - 02:03
Несмотря на отсутствие галки в Состав оборудования и программ, в логе Препайринг и Даунлоад модуля sysinfo идет. Причем успешно )
Что-то пропустил это сообщение.
Это нормально ) Мы отключили только со стороны сервера запрос этой информации, для станций настройка осталась включенной и модуль подгружается.
Хотя, вы про другой модуль говорите, sysinfo это не про "Состав оборудования и программ")
Тут печально другое -- совершенно непонятно пока что, почему при обновлении репозитория с ВСО, _новая_, якобы, ревизия, в итоге, содержит всё тот же битый файл.
#53
Отправлено 02 Март 2018 - 10:48
Всё понятно, почему. Битый файл берётся из кэша, и это осталось прозёвано нами.
Конкретно этот файл можно грохнуть как-то так: rm /var/opt/drwcs/file-cache/36/849aa7381d9027e4438332c52650c036*, предварительно убедившись, что в нём и правда мусор. Можно грохнуть вообще весь файл-кэш, как вариант. Что-то потом повторно выкачается тогда.
#54
Отправлено 02 Март 2018 - 11:02
Не хочу расстраивать но такого пути нет. После file-cashe нет 36.
По поводу нулей в файле. У меня есть одна теория. Правда непонятно почему последующие ревизии то же забиваются нулями. (может это как то взаимосвязано)
В общем, машина в кластере странно переехала (мигрировала), и плюс была болшьшая нагрузка на чтение/запись на внешний рейд массив. Собственно на нем же расположен Cluster Storage.
Вполне возможно это как то повлияло на vhdx файлик... Как можно проверить правильно ли заливается ревизия? Посмотрев в эти файлы revision.xml все последующие то же с нулями.
#55
Отправлено 02 Март 2018 - 11:30
Тогда предлагаю грохнуть (переименовать) file-cache, грохнуть последнюю ревизию агента, рестартовать сервер и запустить обновление.
#56
Отправлено 02 Март 2018 - 11:32
Эй, погодите!
#57
Отправлено 02 Март 2018 - 11:33
я руки от клавиатуры убрал и поднял. !!!
#58
Отправлено 02 Март 2018 - 11:39
Есть ещё вариант поискать, что побито в кэше.
find /var/opt/drwcs/file-cache -type f | sed -r 's/^(.*\/)([^/]+)(\..*$)$/\2 \1\2\3/' > /tmp/md5.sums
md5sum -c --quiet /tmp/md5.sums
Должно сказать, где md5 не соответствует ожидаемому.
#59
Отправлено 02 Март 2018 - 11:45
8 штук не соответствуют.
Сообщение было изменено SiE: 02 Март 2018 - 11:46
#60
Отправлено 02 Март 2018 - 12:00
Меня крайне заинтриговало, что происходит в процессе обновления с ВСО по этому файлу. В пред. логи этого не попало.
Поэтому, давайте, вначале, сделаем вот что:
1. Лог у вас остался дебажный.
2. Если в расписании Сревреа все по дефолту и проверка обновления с ВСо осуществляется раз в полчаса, то хотелось бы получить логи за то тмомент, когда выполнялась проверка.
Или, просто жмакните кнопку "Проверить обновления" в разделе "Администрирование" -> "Состояние репозитория" и опять таки лог за этот временной период.
Ну вы понимаете, да, что он может отротироваться, поэтому может быть drwcsd.log и drwcsd.NUM.log.gz.
rm /var/opt/drwcs/file-cache/36/849aa7381d9027e4438332c52650c036*
Там перед 36 еще id сервера должен быть. Да и хэш странноват.
Но проще найти так:
find /var/opt/drwcs/file-cache -name 2da91c6051d629c7074790ca1800cfa49576f9551fbc9f4f978b92fb3003e8e4*
Кстати, можете его и нам скинуть, или просто глянуть, что там, но там, вероятней всего, всё тоже самое.
И вот после этого, тогда, можно выполнить финт ушами:
/etc/init.d/drwcsd stop
rm -rf /var/opt/drwcs/repository/20-drwagent/??????????????
/etc/init.d/drwcsd syncrepository
/etc/init.d/drwcsd start
Читают тему: 0
0 пользователей, 0 гостей, 0 скрытых