Як встановити розташування основного дамп-файлу (та ім'я)?

Я перебуваю на CentOS 6, намагаюся ввімкнути базові дампи для програми, яку я розробляю. Я поставив:

ulimit -H -c unlimited >/dev/null
ulimit -S -c unlimited >/dev/null

у мій профіль bash, але основний дамп все ще не генерував (у новому терміналі).

Я також змінив /etc/security/limits.conf, щоб м'які межі були нульовими для всіх користувачів.

Як встановити розташування основних файлів для виведення? Я хотів вказати місцеположення та додати час генерування дампа, як частину імені файлу?

Щоб встановити розташування основних дампів у CentOS 6, ви можете відредагувати /etc/sysctl.conf. Наприклад, якщо ви хочете виконувати основні скидання /var/crash:

kernel.core_pattern = /var/crash/core-%e-%s-%u-%g-%p-%t

Де змінні:

% e - ім'я файлу
% g - gid, який процес запускався під
% p - pid процесу
% s - сигнал, який спричинив дамп
% t - час виникнення дампа
% u - це uid, під яким виконувався процес

Також вам доведеться додати /etc/sysconfig/init

DAEMON_COREFILE_LIMIT='unlimited'

Тепер застосуйте нові зміни:

$ sysctl -p

Але є застереження щодо цього. Якщо параметр ядра kernel.core_pattern завжди скидається та перезаписується при перезавантаженні до наступної конфігурації, навіть коли значення вручну вказується в /etc/sysctl.conf:

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

Коротше кажучи, коли abrtd.serviceзапуски kernel.core_patternавтоматично перезаписуються встановленою системою abrt-addon-ccpp. Є два способи вирішити це:

1. Установка DumpLocationопції в /etc/abrt/abrt.confфайлі конфігурації. Каталог призначення може бути визначений, встановивши DumpLocation = /var/crashу /etc/abrt/abrt.confфайлі конфігурації, і sysctl kernel.core_patternвідображене значення збігається, але фактично основний файл буде створений для каталогу в /var/crash.

   Також якщо у вас включений SELinux, вам потрібно запустити:

   $ semanage fcontext -a -t public_content_rw_t "/var/crash(/.*)?"  
   $ setsebool -P abrt_anon_write 1
   

   І нарешті перезапустіть abrtd.service:

   $ service abrtd.service restart
   

2. Зупиніть послугу abrtd. kernel.core_patternне буде переписано. - (Я ніколи не тестував).

Щоб генерувати основний дамп на Busybox, ми можемо додати нижче параметри в сценарій ініціалізації, який запускає наш виконуваний файл. Отже, коли ми ініціалізуємо змінні програмного забезпечення та експорту середовища, ми можемо скопіювати наведені нижче рядки до сценарію, а також скинути ядро ​​у випадку, якщо ми побачимо якийсь збій.

Для встановлення місця розташування основних дампів у Busybox ви можете встановити шлях до основного файлу за допомогою файлової системи proc. Наприклад, якщо ви хочете скидати основні елементи /tmp/crash/corefiles:

mkdir -p /tmp/crash/corefiles
chmod 775 /tmp/crash/corefiles
echo "/tmp/crash/corefiles/%e.%s.core" > /proc/sys/kernel/core_pattern

Де змінні:

% e - ім'я файлу
% g - gid, який процес запускався під
% p - pid процесу
% s - сигнал, який спричинив дамп
% t - час виникнення дампа
% u - це uid, під яким виконувався процес

Крім того, потрібно встановити розмір основного файлу, нижче команда встановлює розмір основного файлу необмеженим

ulimit -c unlimited

Тепер перевірити встановлений розмір основного файлу для кожного потоку в процесі, який ми можемо перевірити

cat /proc/<PID>/limits

Вихід вищевказаної команди:

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        unlimited            unlimited            bytes     
Max open files            10000                10000                files     
Max address space         unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             31868                31868                processes 
Max locked memory         65536                65536                bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       31868                31868                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us      

Як ми бачимо з наведеного вище, вихідний максимальний розмір основного файлу встановлюється необмеженим.

Для отримання додаткової інформації відвідайте це посилання. Методи налагодження програм Linux / Основні файли