Файл дампа памяти не создается

Вопрос или проблема

Вдруг моя служба postgresql начала аварийно завершаться по какой-то причине. Я хотел сгенерировать файл дампа ядра, но файл не генерируется.
Я установил: “ulimit -S -c unlimited”, также добавил строку “*soft core unlimited” в /etc/security/limits.conf.

Также установил путь назначения для kernel.core_pattern=”/coredumps/core-%e-%s-%u-%g-%p-%t”. Кроме того, я выполнил “chmod 777” для пути назначения, чтобы устранить проблемы с разрешениями. Я смог сгенерировать тестовый файл дампа ядра, выполнив “perl -MPOSIX -e ‘$0=”ttt”; pause’ &”, а затем запустив “kill -ABRT”, и файл был сохранен в /coredumps с правильным именем файла.

Когда мой postgres аварийно завершает работу, я вижу в журналах:

Ограничения ресурсов отключают создание дампов ядра для процесса 3607766 (postmaster).

Процесс 3607766 (postmaster) пользователя 26 создал дамп ядра.

[email protected]: Успешно.

Также я заметил разницу между выводами “cat /proc/pid/limits” между моим тестовым процессом и postgresql. У тестового процесса “Максимальный размер файла дампа ядра” установлен на “неограничено”, а значение postgresql “0”
введите описание изображения здесь

Ответ или решение

Проблема с генерацией файлов дампа памяти в PostgreSQL

Ваша ситуация с отсутствием генерации файлов дампа памяти для процесса PostgreSQL, который неожиданно начинает аварийно завершаться, может быть связана с несколькими факторами. Давайте проанализируем, что могло пойти не так и какие шаги можно предпринять для устранения этой проблемы.

1. Ограничения на размер файла дампа

Согласно выводам cat /proc/pid/limits, вы отметили различия между вашими тестовыми процессами и процессом PostgreSQL. В то время как ваш тестовый процесс имеет "Max core file size" установленный на "unlimited", PostgreSQL показывает значение "0". Это говорит о том, что для PostgreSQL установлено ограничение, которое запрещает создание файлов дампа памяти.

Решение: Проверьте, чтобы для вашего пользователя (или группы пользователей) были корректно настроены ограничения в /etc/security/limits.conf. Убедитесь, что строки, подобные следующим, добавлены:

* soft core unlimited
* hard core unlimited

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

2. Параметры среды

Кроме конфигурации в limits.conf, вы также отметили использование команды ulimit -S -c unlimited. Вероятно, это изменение не применимо к родительскому процессу PostgreSQL, который был запущен ранее. Убедитесь, что это значение устанавливается в окружении, в котором запускается PostgreSQL, например:

ulimit -c unlimited

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

3. Настройка системы для генерации дампов

Вы правильно установили kernel.core_pattern="/coredumps/core-%e-%s-%u-%g-%p-%t", что задает шаблон для именования файлов дампа. Убедитесь, что:

  • Директория /coredumps действительно существует.
  • У вас есть необходимые разрешения для записи в эту директорию. Вы установили chmod 777, что должно устранить большинство проблем с правами, но лучше использовать более безопасные разрешения, если это возможно.

4. Перезапуск PostgreSQL

После всех изменений обязательно перезапустите службу PostgreSQL:

sudo systemctl restart postgresql

Или используйте команду, соответствующую вашей системе управления процессами.

5. Проверка системных логов

Если после изменения всех настроек проблема не решается, проверьте системные логи (например, dmesg, /var/log/syslog или /var/log/messages) на предмет дополнительных сообщений об ошибках. Это может дать подсказку по поводу того, почему процесс PostgreSQL не может создать файл дампа памяти.

6. Исправление конфигурации PostgreSQL

Если все вышеперечисленные меры не помогли, возможно, стоит проверить конфигурация PostgreSQL, особенно в отношении параметров log_statement и log_directory, чтобы анализировать логи на наличие паттернов, приводящих к сбоям.

Заключение

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

Оцените материал
Добавить комментарий

Капча загружается...