Docker 中 执行 ‘echo core > /proc/sys/kernel/core_pattern‘ 报错

Docker 中 执行 'echo core > /proc/sys/kernel/core_pattern' 报错

一、背景

前文中,课题组要做AFL的web端可视化展示,需要用Docker封装AFL为WEB API。在改进脚本重新部署后,调用AFL进行fuzzing时,AFL启动失败。因为在执行afl-fuzz前,如果系统配置为将核心转储文件(core)通知发送到外部程序,将导致将崩溃信息发送到Fuzzer之间的延迟增大,进而可能将崩溃被误报为超时。所以得临时修改core_pattern文件,如下所示:

echo core > /proc/sys/kernel/core_pattern

但是在Docker容器中执行上述命令时报错:

bash: /proc/sys/kernel/core_pattern: Read-only file system

大意:core_pattern 为系统只读文件,不能修改

二、疑惑

Docker执行时内部是以root用户执行各种命令,为啥更改不了只读权限的文件呢?带着这个疑问百度了一遍发现也没查出个所以然,就查了一个机翻的帖子也模棱两可的。

既然百度不行,那就Google吧。查了两分钟查到个海峡对岸同胞的博客,找到了解决方案。

三、解决方案

直接上代码:

# 构建容器时加入 --privileged 参数
docker run -idt -p xx:xx --privileged afl-api:0.0.3

如上述命令,在构建容器时多加一个 --privileged参数即可解决问题。

四、原因

大约在0.6版,privileged被引入docker。
使用该参数,container内的root拥有真正的root权限。
否则,container内的root只是外部的一个普通用户权限。
privileged启动的容器,可以看到很多host上的设备,并且可以执行mount。
甚至允许你在docker容器中启动docker容器

——引用自:https://blog.csdn.net/wylfengyujiancheng/article/details/90576040

即加了--privileged参数的容器才能真正执行root权限。

五、参考文献

  • https://ephrain.net/docker-在-container-裡設定-core-dump-的檔案名稱格式/
  • https://blog.csdn.net/wylfengyujiancheng/article/details/90576040
<think>嗯,用户遇到了“No core dump partition found”的错误提示,我需要帮他分析可能的原因。首先,我得回忆一下core dump的基本概念。Core dump是在程序崩溃时生成的内存转储文件,用于调试。这个错误应该和系统无法生成core文件有关。 可能的原因有几个方面。首先是core dump的配置问题,比如是否启用了core dump功能。用户可能没有设置ulimit,或者限制过严。其次是文件系统的问题,比如有没有足够的空间,或者指定的目录是否有写入权限。另外,还要考虑系统是否配置了专用的core dump分区,比如使用systemd的系统可能会用到特定的分区,比如/var/lib/systemd/coredump。 接下来需要考虑不同操作系统的影响。比如,在较新的Linux发行版中,systemd负责core dump,可能需要检查相关的配置,比如/etc/systemd/coredump.conf文件是否正确设置。而传统的系统可能依赖于内核参数,比如kernel.core_pattern的设置是否正确。 还有可能是磁盘空间不足,或者用户没有权限写入目标目录。例如,如果core文件生成到/var/crash,但该目录权限不对,或者磁盘已满,就会失败。此外,如果用户使用了某些安全策略,比如SELinux或AppArmor,可能会阻止生成core文件。 需要一步步引导用户检查这些可能性。首先建议他们检查ulimit的设置,使用ulimit -c看看是否是unlimited。如果不是,就需要修改。然后是检查kernel.core_pattern,确认路径是否正确且可写。接着查看磁盘空间和权限,特别是目标目录。如果是systemd系统,查看coredump的配置和状态。最后考虑安全模块的影响,可能需要临时禁用它们来测试。 用户可能不太熟悉这些配置,所以需要给出具体的命令示例,比如如何修改ulimit,如何查看core_pattern,如何检查磁盘空间等。还要提醒他们在修改配置后可能需要重启服务或系统,比如使用systemctl restart systemd-coredump.service。 另外,要考虑到用户可能是在容器或虚拟化环境中运行,这种情况下core dump可能被进一步限制,需要检查容器配置或宿主机的设置。 总结下来,回答的结构应该分点列出可能的原因,每个原因下给出检查方法和解决步骤,确保用户能逐步排查问题。同时,使用中文,保持清晰易懂,避免使用过于专业的术语,必要时解释每个步骤的目的。</think>### `No core dump partition found` 错误的原因分析及解决方法 #### 1. **核心转储(Core Dump)的基本概念** - 核心转储是程序崩溃时生成的内存快照文件(通常为 `core` 或 `core.PID`),用于调试。 - 错误提示表明系统未找到配置的核心转储存储位置或分区。 --- #### 2. **常见原因** - **原因 1:未配置核心转储分区** - 系统需要指定一个分区或目录存储核心转储文件。若未配置,会触发此错误。 - **检查方法**: ```bash # 查看核心转储路径配置 cat /proc/sys/kernel/core_pattern ``` - **解决**:在 `/etc/sysctl.conf` 中设置 `kernel.core_pattern`,例如: ```bash echo "kernel.core_pattern=/var/crash/core.%e.%p" | sudo tee -a /etc/sysctl.conf sudo sysctl -p ``` - **原因 2:文件系统权限不足** - 目标目录(如 `/var/crash`)权限未开放,或磁盘空间不足。 - **检查方法**: ```bash # 检查目录权限 ls -ld /var/crash # 检查磁盘空间 df -h /var/crash ``` - **解决**:设置目录权限并确保空间充足: ```bash sudo mkdir -p /var/crash sudo chmod 777 /var/crash ``` - **原因 3:核心转储功能未启用** - 系统默认可能限制核心转储大小(通过 `ulimit -c`)。 - **检查方法**: ```bash ulimit -c # 若输出为 0,表示禁止生成核心转储 ``` - **解决**:解除限制: ```bash ulimit -c unlimited # 临时生效 echo "ulimit -c unlimited" >> ~/.bashrc # 永久生效 ``` - **原因 4:使用 systemd 系统的特殊配置** - 在基于 systemd 的 Linux 系统(如 Ubuntu 18.04+)中,需通过 `systemd-coredump` 管理核心转储。 - **检查方法**: ```bash systemctl status systemd-coredump ``` - **解决**:启用并配置 `systemd-coredump`: ```bash sudo systemctl enable systemd-coredump sudo systemctl start systemd-coredump ``` --- #### 3. **验证步骤** 1. 触发一个测试崩溃(例如运行 `kill -s SIGSEGV $$`)。 2. 检查核心转储文件是否生成: ```bash coredumpctl list # systemd 系统 ls /var/crash # 自定义路径 ``` --- #### 4. **扩展注意事项** - **安全性**:开放核心转储可能泄露敏感信息,生产环境需谨慎。 - **容器环境**:在 Docker/Kubernetes 中,需额外配置 `--ulimit core=-1`。 通过逐步排查以上原因并修正配置,可解决 `No core dump partition found` 问题。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值