• Процессы rphost или rmngr внезапно исчезают из списка процессов без сообщений в технологическом журнале.
• Аварийное завершение сеансов пользователей с ошибкой Сеанс работы завершен администратором или Соединение с сервером прервано.
• Необходимость расследования Segmentation Fault (SIGSEGV) и отправки дампов в техподдержку 1С.
• Ядро Linux блокирует запись дампов из-за ограничений ulimit -c 0.

1. Архитектура генерации дампов процессов 1С

При возникновении критической ошибки в C++ коде платформы процесс падает с сигналом SIGSEGV или SIGABRT. Для локализации причин падения ядро ОС должно записать полный слепок памяти упавшего процесса (Core Dump) на диск.

2. Снятие системных лимитов ядра и systemd

Отредактируйте unit-файл службы 1С (/etc/systemd/system/srv1cv8-*.service или override-файл):

[Service]
LimitCORE=infinity
LimitNOFILE=65536

3. Настройка шаблона сохранения дампов ядра

Создайте конфигурационный файл /etc/sysctl.d/99-coredump.conf:

# Шаблон имени дампа: /var/dumps/core-имя_процесса-pid-время
kernel.core_pattern = /var/dumps/core-%e-pid_%p-time_%t
kernel.core_uses_pid = 1
fs.suid_dumpable = 2

Примените параметры:

sudo sysctl --system

4. Подготовка каталога дампов и прав

sudo mkdir -p /var/dumps
sudo chmod 777 /var/dumps
sudo chown usr1cv8:grp1cv8 /var/dumps

5. Перезапуск службы 1С и проверка генерации дампа

sudo systemctl daemon-reload
sudo systemctl restart srv1cv8-8.3.23.1865@default.service

# Тестовая посылка сигнала сброса дампа на рабочий процесс (только на staging)
# kill -SIGSEGV <PID_RPHOST>

6. Первичный анализ дампа в GDB

# Запуск GDB с бинарником 1С и файлом дампа
gdb /opt/1cv8/x86_64/8.3.23.1865/rphost /var/dumps/core-rphost-pid_12345-time_1680000000

# Получение стека вызовов упавшего потока:
(gdb) bt full
(gdb) quit