Внезапное отключение электроэнергии — это всегда стресс для серверного оборудования и баз данных. Одной из специфических проблем, с которой сталкиваются администраторы современных версий платформы 1С (начиная с 8.3.21 и выше), является ошибка выполнения файловой операции, связанная с декомпрессией данных LZ4. Сообщение об ошибке обычно выглядит устрашающе и содержит пути к исходному коду платформы, например: [.../ale/filter/lz4.hpp:76]: Error decompressing LZ4 data. LZ4 error: ERROR_decompressionFailed.
В этой статье мы подробно разберем, почему возникает эта "магическая" ошибка, и пошагово рассмотрим методы её устранения на серверах под управлением Windows и Linux, а также на клиентских машинах.
Прежде всего, проанализируем ситуацию. Начиная с версии 8.3.21, разработчики 1С внедрили алгоритм сжатия LZ4 для оптимизации передачи данных и хранения сеансовой информации. Путь в ошибке, указывающий на D:\Jenkins\ci_builder\..., не означает, что система ищет файлы на вашем диске D. Это техническая информация о том, в какой строке исходного кода (на сборочном сервере фирмы «1С») произошел программный сбой.
Суть проблемы заключается в том, что в момент резкого выключения сервера процесс rphost.exe не успевает корректно завершить запись в файлы сеансовых данных. В результате в кэше сеансов (Session Context) образуется "битый" блок данных. При последующем запуске платформа пытается прочитать этот блок, применить к нему декомпрессию LZ4 и, обнаружив поврежденную структуру, аварийно завершает работу. Рассмотрим, как это исправить, используя в том числе WEB приложение для управления сеансами и процессами rphost — для этого есть готовая WEB-консоль управления кластером 1С.
Наиболее эффективным методом решения данной проблемы является очистка содержимого папок сеансовых данных на сервере 1С. Разберем этот процесс по шагам:
services.msc, найдите службу (например, Агент сервера 1С:Предприятие 8.3 (x86-64)) и нажмите "Остановить".C:\Program Files\1cv8\srvinfo. Если при установке вы меняли путь к данным (параметр -d), используйте ваш актуальный путь.reg_1541 (где 1541 — порт кластера).snccntx (Session Context). Внутри этих папок и хранятся те самые поврежденные файлы .dat.
Важное замечание: Не рекомендуется удалять всю папку srvinfo целиком, так как там хранятся настройки списка информационных баз и журналы регистрации. Нам нужно очистить только содержимое папок, начинающихся на snccntx, для чего можно применить скрипт автоматической очистки серверного кэша.
snccntx-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX и удалите файлы snccntx.dat и snccntx.000000XX.dat.Если ваш сервер работает на ОС Linux, алгоритм действий аналогичен, но команды будут отличаться. Проанализируем стандартную последовательность команд для терминала:
Останавливаем службу сервера (версия платформы может отличаться):
sudo systemctl stop srv1cv8-8.3.22.2143@default.service
Переходим в каталог пользователя, под которым запускается 1С (обычно usr1cv8), и очищаем сеансовые данные. Обратите внимание на путь к папке реестра:
sudo rm -rf /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/snccntx*
Также на Linux рекомендуется очистить временные файлы системы, которые могут содержать остатки битых данных LZ4:
sudo rm -rf /tmp/*
После этого запускаем службу:
sudo systemctl start srv1cv8-8.3.22.2143@default.service
Если очистка кэша 1С не помогла, а вы используете СУБД PostgreSQL, проверьте наличие "зависшего" файла блокировки, который также мог не удалиться после сбоя питания. Рассмотрим процедуру:
postgresql.postmaster.pid (обычно находится в /var/lib/postgresql/data/ или /home/postgres/data/).Иногда ошибка декомпрессии LZ4 может локализоваться в кэше конкретного пользователя на его рабочем месте. Если после очистки сервера ошибка сохраняется на одном компьютере, выполним следующие действия:
%AppData%\1C\1cv8\%LocalAppData%\1C\1cv8\/ClearCache, хотя он очищает только кэш запросов и не всегда эффективен против битых LZ4-данных сеанса.Рассмотрим ситуацию, когда даже после очистки кэша 1С продолжает работать нестабильно. Поскольку питание "обрушилось", могли пострадать индексы самой базы данных или файловая система диска. Выясним, что еще нужно сделать:
Проверка диска: Обязательно выполните проверку тома на наличие логических ошибок командой chkdsk /f C: (для Windows). Это предотвратит повторное повреждение файлов из-за битых секторов или ошибок в таблице MFT.
Тестирование и исправление: Запустите конфигуратор, перейдите в меню "Администрирование" — "Тестирование и исправление". Выберите пункты "Реиндексация таблиц" и "Проверка логической целостности". Это поможет, если повреждение затронуло структуру таблиц в SQL или файловом варианте.
Обновление платформы: Ошибка ERROR_decompressionFailed часто встречалась в ранних релизах ветки 8.3.22. Фирма «1С» выпустила исправления в более свежих релизах, где механизм обработки ошибок LZ4 стал более устойчивым. Посмотрите на возможность обновления платформы до актуального стабильного релиза.
Использование ИБП: Как справедливо заметили участники обсуждения, "сервер без бесперебойника — это источник геморроя". Установка качественного источника бесперебойного питания (ИБП), который может корректно завершить работу сервера при пропадании напряжения, является единственным надежным способом избежать "магических" ошибок 1С в будущем.