86 ответов в этой теме

[SiE]

точно. 9 ку забыл.

Прикрепленные файлы:

•  revision.xml   1,29К   4 Скачано раз

[Kirill Polubelov]

Ну вот, мы почти у цели, еле-еле )

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

[SiE]

Диск? Всмысле виртуальный?

[SiE]

если бы масиив бажил то другие 15 виртуалок бы об этом сказали бы.

Видимо на логические ошибки имеется ввиду?

[Kirill Polubelov]

Файл, как видите, представляет из себя набор 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>

[SiE]

так. Подключился я напрямую к виртуальной машине. Вижу такую надпись: [124554.099449] blk_update_request: I/O error, dev fd0, sector 0

я так понимаю в этом дело?

При этом в консоль (считайте напрямую на сервере) лог дебага шел

 

Что странно, удаленно на "бэды" проверка прошла с 0 ошибками.

 

Я так понимаю ее нужно передернуть? 

Сообщение было изменено SiE: 01 Март 2018 - 21:31

[basid]

Нет, баг ядра Windows?

[SiE]

И причем здесь флоппи? 0_о

[SiE]

DrWeb сервер не может обращаться к флоппи же? ))

[Kirill Polubelov]

Нет, флоппи здесь не причём. Давайте отложим на подумать до завтра )

Есть, конечно, простой вариант, грохнуть этих ревизий и получить их с ВСО по новой. Но как бы понять, отчего так произошло.

[SiE]

давайте. Собственно я его перезапустил из управления Гипер-В пока ошибки этой нет. Но ревизия в нулях. Почитаю еще сам по поводу странного флоппи на виртуальной CentOS .... 

[Kirill Polubelov]

Несмотря на отсутствие галки в Состав оборудования и программ, в логе Препайринг и Даунлоад модуля sysinfo идет. Причем успешно )

 

Что-то пропустил это сообщение.

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

Хотя, вы про другой модуль говорите, sysinfo это не про "Состав оборудования и программ")

 

Тут печально другое -- совершенно непонятно пока что, почему при обновлении репозитория с ВСО, _новая_, якобы, ревизия, в итоге, содержит всё тот же битый файл.

[Afalin]

Всё понятно, почему. Битый файл берётся из кэша, и это осталось прозёвано нами.

Конкретно этот файл можно грохнуть как-то так: rm /var/opt/drwcs/file-cache/36/849aa7381d9027e4438332c52650c036*, предварительно убедившись, что в нём и правда мусор. Можно грохнуть вообще весь файл-кэш, как вариант. Что-то потом повторно выкачается тогда.

[SiE]

Не хочу расстраивать но такого пути нет. После file-cashe нет 36.

По поводу нулей в файле. У меня есть одна теория. Правда непонятно почему последующие ревизии то же забиваются нулями. (может это как то взаимосвязано)

 

В общем, машина в кластере странно переехала (мигрировала), и плюс была болшьшая нагрузка на чтение/запись на внешний рейд массив. Собственно на нем же расположен Cluster Storage.

Вполне возможно это как то повлияло на vhdx файлик... Как можно проверить правильно ли заливается ревизия? Посмотрев в эти файлы revision.xml все последующие то же с нулями.

[Afalin]

Тогда предлагаю грохнуть (переименовать) file-cache, грохнуть последнюю ревизию агента, рестартовать сервер и запустить обновление.

[Kirill Polubelov]

Эй, погодите!

[SiE]

я руки от клавиатуры убрал и поднял. !!! 

[Afalin]

Есть ещё вариант поискать, что побито в кэше.

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 не соответствует ожидаемому.

[SiE]

8 штук не соответствуют.

 

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/5c/59834dae24b15f931cb341b073adb2c3.30: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/0b/14625b5eb7e180106d65945fb0729493.22: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/33/b6291021db64d66b98e1a6b7d798a09c.10: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/d2/0decdd01addebd2b18d6049e202414da.68: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/89/840dfb3f78e79fe24e4151066036bcd3.12448532: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/6f/6ec8ccbb4cf49a76f3429c727c56d471.235945: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/24/25636ea9b92466cf15a6f9a59f8ad296.1325: FAILED

/var/opt/drwcs/file-cache/9d1ec3eb-f96f-472c-b85b-b4e51b7d7f28/b3/39ebbac8f10df691d5ff79f5a20cf731.267970: FAILED

md5sum: WARNING: 1 line is improperly formatted

md5sum: WARNING: 8 computed checksums did NOT match

Сообщение было изменено SiE: 02 Март 2018 - 11:46

[Kirill Polubelov]

Меня крайне заинтриговало, что происходит в процессе обновления с ВСО по этому файлу. В пред. логи этого не попало.

Поэтому, давайте, вначале, сделаем вот что:

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