Файл не обнаружен files sprscndinfo
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.
1C 8.2 8.2.15.315, PostgreSQL 9.0.3, Linux (Centos 6 x86-64). В журналы процесса rphost пишет следующее:
И так почти по всем базам, кроме одной-двух, где, если зайти в БД через SQL, в таблице Files действительно есть строка SprScndInfo, в остальных ее нет. Никаких особо существенных проблем при этом не происходит, но подскажите, пожалуйста, что это вообще за файл и, может быть, кто-то сталкивался с подобной проблемой, как ее можно устранить?
Заранее большое спасибо!
Это уже пройденный этап. Единственная ссылка, не относящаяся к данной ветке конференции - v8: Неправильный путь к файлу 'v8srvr:, и все. К сожалению, полезной информации для именно этого случая там я не увидел.
Уже появилась грешная мысль вручную вбить в SQL-таблицу этот файл :-)
Не-а, апач не при чем. Все указанные рекомендации перепроверил, похоже, не оно. Если честно, у меня больше подозрений на фоновые задания. Недаром же в логах пишется applicationName=BackgroundJob. Видимо, Exception 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3 - это просто совпадение, адрес какого-то объекта.
К апачу вообще никаких претензий,
Ладно, попробую еще одну индейскую народную хитрость, если сработает, отпишусь.
В любом случае, спасибо за помощь!
сполшь веб клиент , арач и иис
Да, конечно, читал, но мои настройки апача совершенно "как учили", и веб-доступ к тестовой базе правильно настроен. Впрочем, конечно, еще раз все перепроверю.
К сожалению, апач не при чем. Переустановил, сделал настройки в точности по руководству 1с. Не оно. Да и если бы апач был виноват, это бы происходило со всеми базами (а их почти 50). Несколько (7 баз) этой проблеме не подвержены. У них есть строка SprScndInfo в таблице Files и по ним, разумеется, никаких записей в журнале не появляется.
Тут вот какое дело: эти записи появляются в журнале с периодичностью строго 150 секунд. Именно такая периодичность у регламентной операции Обновление индекса полнотекстового поиска. Изменяю периодичность запуска этой операции - меняется и периодичность появления записей. Даже при полностью удаленном апаче, удаленных файлах vrd эта проблема присутствует.
Кстати, операция по обновлению индекса у всех баз проходит успешно, ошибок не зафиксировано, более того, операция действительно индексирует новые данные.
Может быть, добавить в настройки журнала какие-нибудь дополнительные свойства событий, чтобы получить больше информации по этому процессу?
Еще добавлю, базы БП редакции 3.0 (есть пара штук для тестирования) нормально работают, в них этой проблемы нет.
Ничего интересного. В разных базах по-разному, но обязательно присутствуют в начале записи символы \x4 (в бинарном формате), смотрел из pgsql запросом
SELECT * FROM Files WHERE filename = 'SprScndInfo';
Длина варьирует от 2 до 150 байт. Дата создания равна дате создания базы, а дата последнего изменения может быть и в апреле, и в феврале этого года. Но вот что интересно, думаю, это как-то связано с обновлением релиза. Слишком уж совпадают даты и время. Перед каждым обновлением релиза я делаю выгрузку в dt (хотя и sql бэкапит каждый день рабочие базы сама по себе), так вот, дата и время последнего изменения этого "файла" SprScndInfo как раз и соответствует окончанию обновления. Но с того момента обновлений было уже много, ИМХО, при обновлении мог возникнуть какой-то конфликт блокировок или одновременного исполнения регламентов. Ладно, копаем дальше.
Еще одно дополнение: пробовал создавать новые базы на сервере, как со своего пользователя и компьютера, так и с других компов в сети и под другими учетными записями, во вновь создаваемых базах любой конфигурации (ЗУП, БП, пустая) строки SprScndInfo в таблице Files нет. Значит, маловероятная проблема с ошибками в UserProfile на моем компе отпадает.
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.
1C 8.2 8.2.15.315, PostgreSQL 9.0.3, Linux (Centos 6 x86-64). В журналы процесса rphost пишет следующее: 05:56.4960-0,EXCP,1,process=rphost,p:processName=base-2012,t:clientID=9084,t:applicationName=BackgroundJob,t:connectID=32049,Exception=9db1fa37-b455-4f3f-b8dd-<. >,Descr="./src/DataSeparationService.cpp(3456): 9db1fa37-b455-4f3f-b8dd-<. >: Файл не обнаружен 'v8srvr://myserv.mydomain.ru/base-2012/Files/SprScndInfo' 9db1fa37-b455-4f3f-b8dd-<. >: Файл не обнаружен 'SprScndInfo'" И так почти по всем базам, кроме одной-двух, где, если зайти в БД через SQL, в таблице Files действительно есть строка SprScndInfo, в остальных ее нет. Никаких особо существенных проблем при этом не происходит, но подскажите, пожалуйста, что это вообще за файл и, может быть, кто-то сталкивался с подобной проблемой, как ее можно устранить? Заранее большое спасибо!
Это уже пройденный этап. Единственная ссылка, не относящаяся к данной ветке конференции - , и все. К сожалению, полезной информации для именно этого случая там я не увидел. Уже появилась грешная мысль вручную вбить в SQL-таблицу этот файл :-)
Не-а, апач не при чем. Все указанные рекомендации перепроверил, похоже, не оно. Если честно, у меня больше подозрений на фоновые задания. Недаром же в логах пишется applicationName=BackgroundJob. Видимо, Exception 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3 - это просто совпадение, адрес какого-то объекта. К апачу вообще никаких претензий, Ладно, попробую еще одну индейскую народную хитрость, если сработает, отпишусь. В любом случае, спасибо за помощь!
Да, конечно, читал, но мои настройки апача совершенно "как учили", и веб-доступ к тестовой базе правильно настроен. Впрочем, конечно, еще раз все перепроверю.
К сожалению, апач не при чем. Переустановил, сделал настройки в точности по руководству 1с. Не оно. Да и если бы апач был виноват, это бы происходило со всеми базами (а их почти 50). Несколько (7 баз) этой проблеме не подвержены. У них есть строка SprScndInfo в таблице Files и по ним, разумеется, никаких записей в журнале не появляется. Тут вот какое дело: эти записи появляются в журнале с периодичностью строго 150 секунд. Именно такая периодичность у регламентной операции Обновление индекса полнотекстового поиска. Изменяю периодичность запуска этой операции - меняется и периодичность появления записей. Даже при полностью удаленном апаче, удаленных файлах vrd эта проблема присутствует.
Кстати, операция по обновлению индекса у всех баз проходит успешно, ошибок не зафиксировано, более того, операция действительно индексирует новые данные. Может быть, добавить в настройки журнала какие-нибудь дополнительные свойства событий, чтобы получить больше информации по этому процессу?
Еще добавлю, базы БП редакции 3.0 (есть пара штук для тестирования) нормально работают, в них этой проблемы нет.
Ничего интересного. В разных базах по-разному, но обязательно присутствуют в начале записи символы x4 (в бинарном формате), смотрел из pgsql запросом SELECT * FROM Files WHERE filename = 'SprScndInfo'; Длина варьирует от 2 до 150 байт. Дата создания равна дате создания базы, а дата последнего изменения может быть и в апреле, и в феврале этого года. Но вот что интересно, думаю, это как-то связано с обновлением релиза. Слишком уж совпадают даты и время. Перед каждым обновлением релиза я делаю выгрузку в dt (хотя и sql бэкапит каждый день рабочие базы сама по себе), так вот, дата и время последнего изменения этого "файла" SprScndInfo как раз и соответствует окончанию обновления. Но с того момента обновлений было уже много, ИМХО, при обновлении мог возникнуть какой-то конфликт блокировок или одновременного исполнения регламентов. Ладно, копаем дальше.
не думаю , коли длинна разная что там посмотрю, но не сегодня. спасибо за наводку про обновления. отпишусь сюда.
Еще одно дополнение: пробовал создавать новые базы на сервере, как со своего пользователя и компьютера, так и с других компов в сети и под другими учетными записями, во вновь создаваемых базах любой конфигурации (ЗУП, БП, пустая) строки SprScndInfo в таблице Files нет. Значит, маловероятная проблема с ошибками в UserProfile на моем компе отпадает.
Не пойму в чем дело Сервер 1С Предприятия: CentOS 5.5 + PostgreSQL 9.0.4 + 1С сервер (8.2.15.319) Клиенты Windows XP/ 7 Два ключа на 5 и 20 юзеров. Стоят на разных виндовских машинах. Периодически выбивает клиентов. В логах постоянно выдает: 00:40.4611-0,EXCP,2,process=rphost,p:processName=buh,t:clientID=2184,t:applicationName=BackgroundJob,t:connectID=1358,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="./src/DataSeparationService.cpp(3456): 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'v8srvr://localhost/buh/Files/SprScndInfo' 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'SprScndInfo'" 00:41.4310-0,EXCP,0,process=rphost,p:processName=buh,Exception=0874860b-2b41-45e1-bc2b-6e186eb37771,Descr='./src/LicenseBaseImpl.cpp(4411): 0874860b-2b41-45e1-bc2b-6e186eb37771: Ошибка программного лицензирования Error=9: Неправильный дескриптор файла File=./src/LicenseBaseImpl.cpp(4352)'
Лучше сделать заранее в /etc/security/limits.conf usr1cv82 soft nofile 4096 usr1cv82 hard nofile 65536
Может я и не догоняю, но вариант клиент серверный. Судя по логам 1С для ragent Похоже все таки на потерю соединения, но на каком это участке: сервер или клиент? 7:12.1445-0,EXCP,3,process=rphost,p:processName=zpl,t:clientID=30,t:applicationName=1CV8,t:computerName=PINT,t:connectID=27,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="./src/DataSeparationService.cpp(3456): 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'v8srvr://gvk/zpl/Files/SprScndInfo' 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'SprScndInfo'" 47:12.2439-0,EXCP,3,process=rphost,p:processName=zpl,t:clientID=30,t:applicationName=1CV8,t:computerName=PINT,t:connectID=27,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="./src/SrvrInfoBaseImpl.cpp(7547): 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'v8srvr://gvk/zpl/Files/SprScndInfo' 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'SprScndInfo'" 48:06.9230-0,EXCP,2,process=rphost,t:clientID=32,Descr='GSS-API error gss_acquire_cred: Unspecified GSS failure. Minor code may provide more information ' 48:06.9232-0,EXCP,2,process=rphost,t:clientID=32,Descr='GSS-API error gss_acquire_cred: . . . . . ' 48:07.1131-0,EXCP,2,process=rphost,p:processName=buh,t:clientID=32,t:applicationName=1CV8,t:computerName=GLAVBUCH,t:connectID=31,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="./src/SrvrInfoBaseImpl.cpp(7547): 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'v8srvr://gvk/buh/Files/SprScndInfo' 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Файл не обнаружен 'SprScndInfo'" 48:48.2730-0,EXCP,2,process=rphost,ClientID=20,Exception=NetDataExchangeException,Descr=Ping time out expired on connection 48:48.2732-0,EXCP,2,process=rphost,ClientID=30,Exception=NetDataExchangeException,Descr=Ping time out expired on connection 48:48.2735-0,EXCP,2,process=rphost,ClientID=28,Exception=NetDataExchangeException,Descr=Ping time out expired on connection 48:48.2736-0,EXCP,2,process=rphost,ClientID=29,Exception=NetDataExchangeException,Descr=Ping time out expired on connection 48:48.2745-0,EXCP,1,process=rphost,p:processName=buh,t:clientID=28,t:applicationName=1CV8,t:computerName=ZLILOVA,t:connectID=23,SessionID=2448,Usr=Жалилова Г.,ClientID=13,Exception=NetDataExchangeException,Descr=' server_addr=tcp://GVK:1541 descr=Победа line=1038 file=./src/DataExchangeTcpClientImpl.cpp' 48:48.5430-0,EXCP,2,process=rphost,ClientID=25,Exception=NetDataExchangeException,Descr=Ping time out expired on connection Не уверен, что это из-за лимитов.
запусти ping -t server >> cllog.log с клиента, и с сервера ping client > srvlog.log. После сбоя посмотреть их и логи центоса и сервера 1с. может что и проявится
Да и у меня не наблюдалось до переустановки системы. Вроде все поставил так же как и всегда. Но вот вываливаться клиенты начали. Клиентов много и разнесены. Всех подряд ставить что ли.
Читайте также: