Генерация дампов ядра в Linux

Question

Что-то очень запутанное происходит в отношении моей коробки.

Ниже приведены мои настройки в /etc/sysctl.conf:

kernel.core_pattern = core
kernel.core_uses_pid = 1

В /etc/profile меня есть это:

ulimit -S -c unlimited >/dev/null 2>1

И я проверяю все, посмотрев на:

cat /proc/sys/kernel/core_pattern
cat /proc/sys/kernel/core_uses_pid

Итак, когда мы делаем ulimit -c , он возвращает значение unlimited .

когда мы делаем ulimit -S -c , он возвращает значение unlimited .

когда мы делаем ulimit -H -c , он возвращает значение unlimited .

И когда я запускаю kill -6 против запущенного процесса, я не получаю ядро.

Когда я запускаю ulimit -c unlimited , запускаю процесс снова и запускаю kill -6 , он генерирует ядро.

Может кто-нибудь объяснить, в чем разница между мягким лимитом и жестким лимитом?

И должны ли мы вообще менять жесткий предел?

Мне не нравится эта ситуация, потому что ядра иногда генерируются, а иногда нет.

Даже если я изменю limit.conf, мне бы очень хотелось понять, что я делаю.

Еще несколько вещей, которые мне нужно раскрыть, это то, что я работаю в среде RHEL 6 (x86_64).

И что на диске достаточно места, и это не процесс DAEMON или программа setuid. И в папке достаточно разрешений для создания новых файлов, и в каталоге времени выполнения нет файлов / папок с именем core.

Answer 1

Вы можете прочитать о жестких и мягких ограничениях в разделе руководства по Bash на ulimit.

Поскольку вы говорите, что получаете основной файл, если перезапускаете программу из своей оболочки, проблема, вероятно, заключается в том, что исходный процесс не запускается в среде, которая читает /etc/profile (этот файл только для чтения для оболочек входа в систему). Вы можете рассмотреть возможность добавления ulimit -c unlimited в любой скрипт, запускающий эту программу (конечно, перед строкой, которая ее запускает).

Answer 2

Таким образом, единственная причина, по которой это происходило, заключалась в том, что скрипт запускался в приглашении sh, в отличие от приглашения bash, где был установлен ulimit. Разве это не странно? Мы изменили скрипт для запуска в bash, и теперь он работает нормально.