В настоящее время я изучаю проблему с нашим программным обеспечением, касающуюся отсутствия coredumps
Установка: Мы запускаем приложение (c ++) (myapp), которое изначально запускается как подпроцесс программой python, которая выполняется как root. Программа python, однако, снижает привилегии приложения c ++ и запускает его как отдельный пользователь (myuser). В основном это делается, как в Запуск дочерних процессов от имени другого пользователя от продолжительного Python процесса
Проблема: мы наблюдаем за этим процессом, и недавно у нас был cra sh, где мы могли выяснить, что программа прерывается (SIGABRT), но не записан файл core.
Попытка решить проблему: I посмотрел Файл дампа ядра не генерируется и попытался выяснить некоторые распространенные проблемы
$ ulimit -c
unlimited
$ /proc/sys/kernel/core_pattern
/tmp/core%e%t
(или что-то похожее)
Выглядит пока хорошо - затем я проверил проблему с setuid, упомянутым в другом потоке stackoverflow
$ cat /proc/sys/fs/suid_dumpable
0
, который, похоже, указывает на то, что это может остановить генерацию corefiles. Также есть решение (а именно вызов prctl). Чтобы надежно протестировать проблему и посмотреть, будет ли работать решение с вызовом prctl (PR_SET_DUMPABLE, 1, ...), я сначала попытался воспроизвести проблему, вручную отправив в приложение SIGABRT.
Теперь странная вещь: после отправки SIGABRT был сгенерирован файл core. Итак, подведем итог - генерация corefile, кажется, работает в принципе - когда отправляется SIGABRT. - генерация corefile не всегда работает. Это будет означать, что вызовы setuid из скрипта python не будут вообще препятствовать генерации corefile.
У кого-нибудь есть идеи, как go с этого момента?