Здравствуйте, господа,

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, в остальных ее нет. Никаких особо существенных проблем при этом не происходит, но подскажите, пожалуйста, что это вообще за файл и, может быть, кто-то сталкивался с подобной проблемой, как ее можно устранить?

Заранее большое спасибо!

315 - тестовая

Это я знаю, там в сущности немного отличий от стабильной 310-й, главное, исправлена ошибка, с которой мы сталкивались.
Описанные сообщения в журнале были во всех использовавшихся версиях платформы, начиная с 8.2.14.540, более ранние не проверял.

что-то с вебсервисами связано

Странно... Конфигурации - БП и ЗУП (последние), там нет веб-сервисов. Или я не понял?

(4)
гуглите по "SprScndInfo"

Это уже пройденный этап. Единственная ссылка, не относящаяся к данной ветке конференции - v8: Неправильный путь к файлу 'v8srvr:, и все. К сожалению, полезной информации для именно этого случая там я не увидел.
Уже появилась грешная мысль вручную вбить в SQL-таблицу этот файл :-)

я смотрел по номеру Exception 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3

Спасибо большое, попробую

Не-а, апач не при чем. Все указанные рекомендации перепроверил, похоже, не оно. Если честно, у меня больше подозрений на фоновые задания. Недаром же в логах пишется applicationName=BackgroundJob. Видимо, Exception 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3 - это просто совпадение, адрес какого-то объекта.
К апачу вообще никаких претензий,
Ладно, попробую еще одну индейскую народную хитрость, если сработает, отпишусь.
В любом случае, спасибо за помощь!

(9)
http://www.google.ru/search?ie=UTF-8&hl=ru&q=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3

сполшь веб клиент , арач и иис

Да, конечно, читал, но мои настройки апача совершенно "как учили", и веб-доступ к тестовой базе правильно настроен. Впрочем, конечно, еще раз все перепроверю.

К сожалению, апач не при чем. Переустановил, сделал настройки в точности по руководству 1с. Не оно. Да и если бы апач был виноват, это бы происходило со всеми базами (а их почти 50). Несколько (7 баз) этой проблеме не подвержены. У них есть строка SprScndInfo в таблице Files и по ним, разумеется, никаких записей в журнале не появляется.
Тут вот какое дело: эти записи появляются в журнале с периодичностью строго 150 секунд. Именно такая периодичность у регламентной операции Обновление индекса полнотекстового поиска. Изменяю периодичность запуска этой операции - меняется и периодичность появления записей. Даже при полностью удаленном апаче, удаленных файлах vrd эта проблема присутствует.

интересно.

Кстати, операция по обновлению индекса у всех баз проходит успешно, ошибок не зафиксировано, более того, операция действительно индексирует новые данные.
Может быть, добавить в настройки журнала какие-нибудь дополнительные свойства событий, чтобы получить больше информации по этому процессу?

Еще добавлю, базы БП редакции 3.0 (есть пара штук для тестирования) нормально работают, в них этой проблемы нет.

с такой информацией уже можно посмотреть , что в SprScndInfo

Ничего интересного. В разных базах по-разному, но обязательно присутствуют в начале записи символы \x4 (в бинарном формате), смотрел из pgsql запросом
SELECT * FROM Files WHERE filename = 'SprScndInfo';
Длина варьирует от 2 до 150 байт. Дата создания равна дате создания базы, а дата последнего изменения может быть и в апреле, и в феврале этого года. Но вот что интересно, думаю, это как-то связано с обновлением релиза. Слишком уж совпадают даты и время. Перед каждым обновлением релиза я делаю выгрузку в dt (хотя и sql бэкапит каждый день рабочие базы сама по себе), так вот, дата и время последнего изменения этого "файла" SprScndInfo как раз и соответствует окончанию обновления. Но с того момента обновлений было уже много, ИМХО, при обновлении мог возникнуть какой-то конфликт блокировок или одновременного исполнения регламентов. Ладно, копаем дальше.

там зип без заголовка - стандартный 1ский трюк

То есть, это просто "флажок"? И можно вручную добавить такую запись в таблицу БД?

не думаю , коли длинна разная
что там посмотрю, но не сегодня.

спасибо за наводку про обновления. отпишусь сюда.

Вам спасибо!

Еще одно дополнение: пробовал создавать новые базы на сервере, как со своего пользователя и компьютера, так и с других компов в сети и под другими учетными записями, во вновь создаваемых базах любой конфигурации (ЗУП, БП, пустая) строки SprScndInfo в таблице Files нет. Значит, маловероятная проблема с ошибками в UserProfile на моем компе отпадает.

8.2.15.318 - ошибка так и есть.