当我从通常核心的 cron 运行某些东西时，我怎样才能获得核心转储？

Posted 2023-02-22

【中文标题】当我从通常核心的 cron 运行某些东西时，我怎样才能获得核心转储？

【英文标题】：How can I still get my core dump when I run something from cron which would normally core?

【发布时间】：2012-09-07 22:07:34

【问题描述】：

今天，我 cron 并尝试检测核心转储并提醒我的某些事情实际上遇到了错误的断言（当我在前台或后台的命令行上运行它时，通常核心会转储它）但没有核心倾倒。我写了这个简单的测试：

int main

sleep(3);
assert(false);

当我编译和运行时，它会一直进行核心转储。但是当我把它放在 crontab 上时，我收到了一封来自 cron 守护进程的电子邮件：

rocket: main.cpp:10: int main(int, char**): Assertion `false' failed.
/bin/sh: line 1: 32448 Aborted                 ./rocket

并且从未将核心文件放置在/cores 中。为什么会这样？如何获得我的核心？

【问题讨论】：

这是哪个操作系统？为什么你期望在 /cores 中加入一些东西？ （我的任何 Linux 系统上都没有 /cores）

它是红帽 Linux。我猜它必须被配置为执行此操作。很好的观察虽然..工作目录也没有核心文件... cron 有放置核心的地方吗？

【参考方案1】：

要在崩溃时生成核心文件，必须在当前环境中启用核心转储。在 shell 中，这可以使用 ulimit 来完成：

ulimit -c unlimited

这意味着“将最大核心转储大小设置为无限制”。您的系统可能配置为在交互式 shell 中执行此操作，但不是在 cron 作业中。要从 cron 作业执行此操作，您需要修改此限制。如果 cron 作业是一个调用其他程序的 shell 脚本，你可以像上面那样调用ulimit。另一方面，如果作业是可执行文件，您可以创建一个包装器来运行它：

#!/bin/bash
ulimit -c unlimited
exec "$@"

另一种选择是修改程序以使用setrlimit 函数自行设置限制。

至于为什么你的核心进入 /cores 而不是工作目录：你的发行版可能已经调整了 core pattern，可能使用了一个程序来处理核心文件并将它们放在 /cores 中。