ubuntu默认在稳定版中禁用apport（enabled=0），需手动编辑/etc/default/apport设为enabled=1并重启服务，同时清空/var/crash/残留文件才能启用崩溃报告；其存储数量由/etc/apport/crashdb.conf中maxreports参数限制，默认路径/var/crash不可更改。
如何启用或禁用Apport崩溃报告
Ubuntu默认在桌面版中启用Apport，但稳定发行版（如20.04 LTS、22.04 LTS）常将其设为enabled=0，导致程序崩溃时静默退出、无弹窗。必须手动开启才能触发.crash文件生成和用户通知。
编辑配置文件：sudo nano /etc/default/apport，将enabled=0改为enabled=1；保存后执行sudo systemctl restart apport生效。注意：仅改配置不重启服务，apport不会监听崩溃事件。
- 若系统已存在旧崩溃残留，启动后仍不弹窗，先清空
/var/crash/目录（sudo rm /var/crash/*.crash） - 某些桌面环境（如GNOME on Wayland）可能抑制图形化弹窗，可临时切到TTY（Ctrl+Alt+F3）运行测试程序验证
- 修改后建议用
kill -SEGV $$测试当前shell是否触发报告——成功会立即生成/var/crash/_bin_bash.*.crash
如何控制崩溃报告的存储数量和位置
Apport默认把所有.crash文件存进/var/crash/，不自动清理，磁盘占满后可能影响系统稳定性。限制数量靠/etc/apport/crashdb.conf里的MaxReports参数，而非日志轮转工具。
编辑sudo nano /etc/apport/crashdb.conf，找到"MaxReports"字段（通常在default段），例如设为50：
"MaxReports": 50,该值表示本地最多保留50个未发送的.crash文件；超过后，最老的会被自动删除。
-
MaxReports只影响/var/crash/下的文件数，不影响已上传到Launchpad的报告 - 路径不可更改——Apport硬编码使用
/var/crash，试图通过符号链接或bind mount绕过可能导致报告丢失 - 若需归档历史报告，应定期
mv /var/crash/*.crash /some/backup/，再sudo rm /var/crash/*.crash
如何区分Apport报告和kdump内核崩溃报告
普通用户程序崩溃（如Firefox闪退、Python脚本报错）走Apport流程，生成.crash文本报告；而内核panic（黑屏、系统卡死）由kdump捕获，生成二进制vmcore或压缩vmcore-dmesg.txt，两者完全独立，配置互不影响。
Ubuntu 26.04 LTS（代号“Resolute Raccoon”）是Canonical于2026年4月23日发布的下一代长期支持版操作系统，提供长达10年的技术支持。它搭载Linux 7.0内核与GNOME 50桌面环境，全面转向Wayland协议，并引入Rust重写的核心工具以增强安全性。官方提供适用于AMD64和ARM64架构的桌面及服务器ISO镜像，是追求前沿技术与极致稳定的开发者
验证当前是否启用kdump：kdump-config show输出含ready to kdump且systemctl status kdump-tools为active才有效；Apport则只管用户空间进程，对echo c > /proc/sysrq-trigger无反应。
- Apport报告里
Package字段标识出错的deb包名（如firefox:amd64 125.0.1+build1-0ubuntu0.22.04.1） - kdump报告存于
/var/crash/但文件名含vmcore或kernel_前缀，且需要crash工具解析 - 同时开启两者时，
/var/crash/下可能混存两类文件，勿误删vmcore类文件
为什么改了ulimit -c unlimited还是没生成core文件
Apport和core dump是两套机制：即使ulimit -c unlimited生效，只要Apport启用，它会拦截SIGSEGV等信号并生成.crash文件，**同时阻止core文件落地**——这是设计行为，不是bug。
若你明确需要core文件（比如用gdb ./a.out core调试），必须关掉Apport：sudo sed -i 's/enabled=1/enabled=0/' /etc/default/apport && sudo systemctl restart apport，再确认cat /proc/sys/kernel/core_pattern不是|/usr/share/apport/apport %p %s %c %d %P %E（这是Apport接管的标志）。
- 检查core_pattern是否被Apport劫持：
grep -q "apport" /proc/sys/kernel/core_pattern && echo "Apport active, core disabled" - 恢复core生成后，建议用
echo "/tmp/core.%e.%p" | sudo tee /proc/sys/kernel/core_pattern指定路径，避免写满根分区 - 容器内运行的程序受宿主机Apport影响，即使容器里
ulimit设对了，宿主机Apport仍可能吞掉信号
