У нас есть собственный демон, работающий на нескольких серверах RHEL 5, которые периодически выходят из строя. Наши разработчики хотят, чтобы файл ядра помогал с отладкой, но я не могу спровоцировать его на создание такого файла.
$ sudo grep segfault /var/log/messages.1
Aug 11 21:04:13 pal108 kernel: brokend[28692]: segfault at 00000000000000a8
rip 00000031d020f908 rsp 00007fff9c60f3f0 error 4
Демон запускается с использованием daemon из /etc/init.d/functions, поэтому добавляем
DAEMON_COREFILE_LIMIT=unlimited
к его sysconfig файл должен установить ulimit соответственно. Похоже, что это так, согласно procfs:
$ sudo grep core /proc/$(cat /var/run/brokend.pid)/limits
Max core file size unlimited unlimited bytes
И шаблон основного файла указывает на существующее местоположение:
$ cat /proc/sys/kernel/core_pattern
"/tmp/core_%p_%e_%t"
Тем не менее, он по-прежнему не создает файл ядра. Есть идеи, что могло бы остановить это? Имеет ли segfault всегда означает, что ОС будет пытаться создать файл ядра или для этого полагается на кодировку для конкретного приложения?
Установлен ли демон setuid? Процессы setuid по умолчанию не сбрасывают файлы ядра.
Бегать sysctl fs.suid_dumpable=1 для включения дампов setuid.
Да, резервные дампы всегда записываются, когда сигнал отправляется процессу, который производит ядро, например:
ABRT 6 core
FPE 8 core
ILL 4 core
QUIT 3 core
SEGV 11 core
TRAP 5 core
SYS core might not be implemented
EMT core might not be implemented
BUS core core dump might fail
XCPU core core dump might fail
XFSZ core core dump might fail
ulimit должен быть установлен (как вы уже упоминали). так как я так мало знаю redhat, я бы проверил, установлен ли ulimit под пользователем, которым вы запускаете deamon. я бы просто поставил
echo -n "ulimit: "
ulimit -c
echo -n "For id: "
id -u
echo
в скрипте, чтобы проверить это.
Посмотрите "man core", там есть пример кода для тестирования функции coredump. По крайней мере, под debian есть.