Диагностика падения процесса 1С в Linux

Repo script: ./scripts/diag/technological-log.sh

technological-log.sh читает ограниченный технологический журнал запуска (status, cursor read, restore). Для журнала сервера площадки используйте обёртку управления техжурналом модуля customer-site-operations, если модуль материализован в infra/site/.

Результат

Минимальная доказательная цепочка:

завершение процесса -> механизм сбоя -> сообщение исключения -> live-причина -> исправление -> приёмка.

Соседнее предупреждение, недавно установленный пакет или изменение лицензирования не считаются причиной без прямой связи с этой цепочкой.

Обязательные ограничения

• Начинайте с проверок только на чтение. Перезапуск службы, изменение политики core, установка пакета, исправление файла и очистка артефактов требуют отдельного явного разрешения.
• Не выводите сырой технологический журнал, продолжения SQL, /proc/*/cmdline, аргументы процессов (ps args), core или память процесса: там могут быть параметры авторизации. Наружу отдавайте разрешённый список полей, счётчики и короткие подтверждённые фрагменты сообщений.
• Каталоги для core и диагностики создавайте доступными только root. Не удаляйте их без отдельного разрешения: они могут содержать секреты и остаются доказательством.
• Не отключайте защиту ptrace, MAC или режимы защищённой ОС ради удобства диагностики.
• Не устанавливайте gdb, strace или отладочные символы без явного решения. Сначала проверьте штатную альтернативу.
• Команды через удалённый рабочий стол выполняйте по правилам площадки из docs/infra/site/, если модуль площадки материализован.

Порядок диагностики

1. Доказать факт и вид завершения

Снимите PID и время старта процесса, затем отслеживайте только безопасные поля /proc/PID/stat: состояние, статус ожидания, сигнал и код. Отличайте исчезновение PID от zombie. Для SIGABRT ожидается сигнал 6; сообщение systemd само причину abort не раскрывает. Если PID переиспользован или время старта изменилось, начните наблюдение заново.

2. Проверить, отвечает ли техжурнал на вопрос

Используйте существующую обёртку техжурнала, если она подходит установленной версии. Сначала проверьте её контракт и конфигурацию, затем соберите ограниченный интервал вокруг сбоя.

Техжурнал не является построчным CSV. При анализе EXCP и EXCPCNTX:

1. принимайте только подтверждённые заголовки событий;
2. считайте события по process, а не по глобальному счётчику;
3. отдельно покажите счётчики целевого процесса и событий без process;
4. если у упавшего процесса EXCPCNTX=0, зафиксируйте предел техжурнала и переходите к core, не приписывая ему контексты ragent, rmngr или клиента.

Kerberos, лицензия и другие предупреждения остаются сопутствующими, пока стек, исключение или воспроизводимая операция не связали их с abort.

3. Выбрать трассировку процесса или core

До подключения отладчика проверьте наличие инструмента и текущую политику ptrace. Если подключение запрещено политикой, не ослабляйте её: используйте имеющийся core или согласуйте одноразовый захват core.

До захвата снимите только чтением:

• kernel.core_pattern и kernel.core_uses_pid;
• LimitCORE целевой службы systemd;
• фактические мягкий и жёсткий лимиты core процесса;
• состояние службы и точное имя unit;
• свободное место и каталог назначения, доступный только root.

4. Захватить ровно один core

Это отдельное изменение рабочей среды. После разрешения временно задайте минимальную настройку службы и политики core, перезапустите точный unit, дождитесь одного подтверждённого падения и сразу восстановите исходные значения.

• Откат выполняется обработчиком trap и повторно проверяется после команды.
• Каталог абсолютный, с непредсказуемым именем, доступен только root.
• Сохраняются точный путь бинарника, PID и время старта, unit и время сбоя.
• Поиск core динамический и требует ровно одного непустого кандидата.
• После восстановления служба проверяется отдельно.

5. Получить ограниченный backtrace

Запускайте GDB над точным бинарником упавшего процесса и выбранным core. Сначала проверьте опции установленной версии GDB; для старой версии не переносите современные команды. Автозагрузку ограничивайте поддерживаемой командой set auto-load safe-path /nonexistent.

Снимите ограниченный backtrace и список модулей. Цепочка raise -> abort -> __gxx_personality_v0 -> _Unwind_* доказывает abort при обработке C++-исключения, но не его первопричину. Адреса без символов сохраняйте вместе с точными версиями бинарника и разделяемых библиотек; не называйте ?? функциями по догадке.

6. Восстановить тип и сообщение исключения

Используйте только ABI и исходники, соответствующие реально загруженной libstdc++. Сначала докажите расположение _Unwind_Exception, брошенного объекта и type info для этой версии. Не переносите числовые смещения между версиями.

Перед удалённой командой проверьте выражения GDB на маленьком локальном C++-примере с тем же ABI. Затем двигайтесь от общего к частному:

1. определите класс исключения;
2. получите type info и имя типа;
3. исследуйте только небольшой ограниченный диапазон памяти объекта;
4. проверяйте указатели перед разыменованием;
5. декодируйте строку только после доказательства её расположения и кодировки.

Первое похожее поле может быть кодом или вложенным объектом, а не char*. Ошибка чтения памяти опровергает гипотезу и не является поводом расширить дамп. Для UTF-16 используйте строковый формат GDB только после проверки адреса и смещения на локальном примере.

7. Превратить сообщение в live-доказательство

Сообщение исключения задаёт следующую узкую проверку, но не всегда буквально описывает системную ошибку. Для файла отдельно проверьте:

• существование и тип;
• владельца, группу, права и временные метки;
• доступность каждого компонента пути;
• чтение от имени фактического пользователя процесса через runuser из /;
• версионные и общие варианты пути;
• состояние сопоставимого исправного узла, только если его роль и набор ПО совпадают.

Так различаются реальный ENOENT, EACCES и прикладное сообщение «не найден». Новые Java, Ring, Kerberos или лицензия не становятся причиной только из-за совпадения по времени. Отдельно фиксируйте непосредственную причину и, если не доказано, неизвестное происхождение изменения.

8. Исправить минимально и провести приёмку

После явного разрешения меняйте только доказанный объект. Не исправляйте пакет, лицензию или топологию по сопутствующим предупреждениям.

Приёмка снизу вверх:

1. целевой ресурс доступен от имени фактического пользователя процесса;
2. PID и время старта наблюдаемого процесса не сменились, состояние не zombie;
3. процесс стабилен в согласованном окне наблюдения;
4. список рабочих процессов кластера через RAS (process list, по навыку 1c-rac-operations) подтверждает состояние running для нужного кластера;
5. реальная клиентская операция через rphost завершается успешно.

Активная служба systemd или один живой PID не заменяют пункты 4 и 5.

Что сохранить

В репозитории фиксируйте без секретов: точный набор версий, время сбоя, сигнал и код, значимые счётчики техжурнала, ограниченный стек, тип и короткое сообщение исключения, проверку причины от имени пользователя процесса, минимальное изменение и все ступени приёмки. Полный core, сырой техжурнал и дампы памяти в Git не помещайте.

Отдельно перечислите недоказанные гипотезы и оставшуюся очистку: core, временный техжурнал, диагностические пакеты и служебные каталоги. Очистку выполняйте отдельным согласованным действием.

Условия остановки

Остановитесь и запросите решение, если требуется ослабить защиту, установить пакет, перезапустить рабочую службу, изменить политику core, исправить данные или права либо удалить доказательства. Прекратите ветку гипотезы, если её предсказание опровергнуто live-проверкой; не компенсируйте это более широким сбором потенциально секретных данных.