Курс валют не обновился, обмен не выгрузил документы, а пользователь видит только вчерашние данные. Перезапуск сервера сейчас лишит вас самой полезной улики: какие задания стояли в очереди и на чём остановились.
Сначала выберите одно конкретное задание. Запишите его имя, ожидаемое время запуска, последний успешный запуск и статус последней попытки. Фраза «фоновые задания не работают» слишком широкая для диагностики.
Четыре разных состояния с одним симптомом
| Что видно | Вероятный слой | Следующий шаг |
|---|---|---|
| Задание выключено | Настройка прикладного решения | Проверить флаг использования |
| Следующий запуск не рассчитан | Расписание | Открыть расписание и рабочие дни |
| Все задания не стартуют | Запрет инфобазы или планировщик | Проверить свойства базы и кластер |
| Одно задание падает | Код, данные, блокировка, СУБД | Открыть сообщение и журнал регистрации |
Порядок проверки
- В типовой конфигурации откройте раздел администрирования и форму регламентных и фоновых заданий.
- Найдите одно проблемное задание. Проверьте «Использование», расписание, последний запуск и сообщение об ошибке.
- Если операция безопасна, нажмите Выполнить сейчас один раз. Не запускайте массовую синхронизацию повторно без бизнес-ID.
- Если не стартует ничего, откройте свойства информационной базы в консоли кластера и проверьте запрет регламентных заданий.
- Сопоставьте время попытки с журналом регистрации и активными сеансами.
- После исправления дождитесь одного запуска по расписанию. Ручной успех ещё не проверяет планировщик.
Проверка кластера через rac
Команды зависят от версии платформы и адреса агента. Не копируйте UUID из примера. Сначала получите список кластеров и баз, затем подставьте найденные значения.
# Linux: путь rac зависит от установленной версии платформы
/opt/1cv8/x86_64/<version>/rac cluster list 127.0.0.1:1545
/opt/1cv8/x86_64/<version>/rac infobase summary list --cluster=<cluster-uuid> 127.0.0.1:1545
# Снимок процессов и нагрузки ОС до перезапуска
ps -eo pid,etimes,%cpu,%mem,cmd | grep -E 'ragent|rmngr|rphost' | grep -v greprac требует корректной административной аутентификации, если она настроена. Не добавляйте пароль в историю shell. Для изменения запрета используйте администраторскую консоль и зафиксируйте, почему он был включён.
PASS и FAIL
- PASS: ручной тест создал один фоновый запуск и он завершился без ошибки.
- PASS: следующий запуск появился по расписанию и выполнился сам.
- PASS: после обслуживания запрет снят осознанно, а не случайным переключением.
- FAIL: задание висит «Выполняется», но его сеанса уже нет.
- FAIL: после ручного успеха плановый запуск снова не появился.
Где ошибаются
Смотрят только расписание. Оно может быть правильным, пока вся инфобаза находится под административным запретом. Это частый хвост после обновления или тестового переноса.
Снимают запрет без контекста. Его могли включить перед обменом, реструктуризацией или восстановлением. Сначала узнайте, закончена ли операция.
Повторяют тяжёлое задание. Первый экземпляр ещё работает, второй ждёт те же ресурсы. Сопоставьте фоновые задания с сеансами и блокировками.
Путают файловую и серверную базу. В файловом режиме планировщик зависит от клиентского приложения или web extension. Серверные команды кластера там не помогут.
Чек-лист восстановления
- Имя и расписание задания зафиксированы.
- Последний успешный запуск известен.
- Флаг использования включён.
- Запрет на инфобазе проверен.
- Ошибка сопоставлена с журналом регистрации.
- Проверены ручной и следующий плановый запуск.
Отделите запрет планировщика от ошибки обработчика
Если кнопка «Выполнить сейчас» создаёт задание, но оно падает, планировщик уже сделал свою работу. Дальше разбирайте сообщение конкретного обработчика: права пользователя, блокировку данных, сетевой ресурс, обмен или СУБД. Если запись о запуске вообще не появляется, оставайтесь на уровне расписания, использования и административного запрета.
Сравните одно рабочее и одно проблемное задание. Если оба запускаются одним механизмом, но падает только одно, глобальный рестарт кластера почти наверняка лишний. Запишите длительность, пользователя, приложение, ключ задания и текст исключения. Для повторяемой ошибки этого обычно хватает, чтобы сузить модуль.
Наблюдение после исправления
- очередь не растёт между двумя контрольными замерами;
- одно и то же регламентное задание не выполняется параллельно без причины;
- последний успешный запуск обновляется по расписанию;
- в журнале регистрации нет повторяющейся ошибки;
- обмен создал ожидаемое число объектов без дублей.
Для заданий, которые обращаются к файлам или сети, проверьте контекст серверного процесса. Интерактивный пользователь может видеть сетевой диск, а служба 1С — нет. Используйте UNC-путь и права учётной записи службы, не букву диска из пользовательской сессии.
Если после обновления конфигурации запрет снимается автоматически, всё равно проверьте первый плановый запуск. Ручной запуск из вашей сессии может иметь другие права и не воспроизводить серверное выполнение.
Зафиксируйте контрольное время следующего запуска и поставьте короткое наблюдение. Если отметка снова не обновилась, вернитесь к состоянию планировщика, не повторяя обработчик вручную.
Что делать, если не помогло
Не завершайте процессы вслепую. Снимите список фоновых заданий, сеансов, блокировок и событий журнала за узкое окно времени. Если задание ждёт ресурс, используйте инструкцию про поиск блокирующего сеанса. Для короткого трассировочного окна пригодится технологический журнал 1С. Мы можем диагностировать и настроить 1С, сохранив картину сбоя до изменений.
