ulimit -c 输出为 0 表示当前 shell 会话禁用 core dump，不生成任何 core 文件；需结合 /proc/sys/kernel/core_pattern 判断存储位置或是否由 systemd-coredump 管理，再用 coredumpctl 查看。
ulimit -c 输出为 0 就表示禁用 core dump
直接运行 ulimit -c 是最快速的判断方式。输出数字代表当前 shell 会话允许生成的 core 文件最大字节数；若为 0，说明该会话下任何进程崩溃都不会生成 core 文件。这不是“没找到”，而是根本没开——很多线上服务器默认就是 0。
注意：ulimit -c 只反映当前 shell 的限制，不等于系统全局状态。子进程继承这个值，但其他登录会话、systemd 服务、容器内进程可能各自独立受限。
/proc/sys/kernel/core_pattern 决定 core 文件去哪、叫啥名
运行 cat /proc/sys/kernel/core_pattern 查看内核实际使用的路径模板。常见结果有：
-
core：默认行为，写入当前工作目录，文件名固定为core -
/var/core/core.%e.%p：写入指定目录，按程序名和 PID 命名 -
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h：表示走 systemd-coredump 管道，此时不会落地为普通文件，得用coredumpctl查
如果看到管道符 |，就别在文件系统里翻 core 了——coredumpctl list 才是正确入口。
limits.conf 里的 * soft core unlimited 不一定已生效
即使你在 /etc/security/limits.conf 里写了：
* soft core unlimited* hard core unlimited
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
也得确认两点：
- 用户是否已重新登录（SSH 重连或图形界面重新登录），否则新限制不加载
- 服务是否由 systemd 启动：systemd 忽略 limits.conf，需在 service 文件里显式加
LimitCORE=infinity
验证方式：启动一个测试进程（比如 sleep 1000 &），再用 cat /proc/$(pidof sleep)/limits | grep core 看它实际拿到的 limit。
systemd 系统里 coredumpctl 比找文件更可靠
现代发行版（Ubuntu 16.04+/CentOS 8+/RHEL 8+）默认启用 systemd-coredump，core 文件被压缩存到 /var/lib/systemd/coredump/，且按 UID、时间戳等索引。直接查目录容易漏，应优先用：
coredumpctl list —— 列出所有已捕获的崩溃coredumpctl info myapp —— 查指定程序最近一次崩溃详情coredumpctl debug myapp —— 自动拉起 gdb，加载对应二进制和符号
它自动处理路径、权限、调试符号匹配，比手动拼 gdb ./myapp core 少踩一半坑。
真正麻烦的不是“怎么开”，而是“开了却找不到”——往往因为路径不对、权限不够、被 systemd 拦截、或者服务跑在容器里没透传 ulimit。先盯住 ulimit -c 和 core_pattern 这两个点，再决定下一步查文件系统还是查 coredumpctl。
