Ubuntu18.04系统设置ulimit

一.配置文件所在目录:

sudo vim /etc/security/limits.conf

二.修改Limit.conf文件

* soft nproc 65535

* hard nproc 65535

* soft nofile 65535

* hard nofile 65535

 

root soft nproc 65535

root hard nproc 65535

root soft nofile 65535

root hard nofile 65535

 

liuxiaowei soft nproc 65535

liuxiaowei hard nproc 65535

liuxiaowei soft nofile 65535

liuxiaowei hard nofile 65535

注:liuxiaowei是普通用户

三.添加 common-session

在 /etc/pam.d/common-session 和 /etc/pam.d/common-session-noninteractive  文件中,都添加下面内容:

session required pam_limits.so

四.修改 /etc/systemd/system.conf 文件

#DefaultLimitNOFILE=65536

将前面的#去掉

五.重启

修改完成后,如果是远程链接,重新链接即可生效; 如果是桌面环境,重启后生效。

六.说明

1. nproc 是操作系统级别对每个用户创建的进程数的限制。

2. nofile 最大打开文件描述符数, too many open files 的时候一般就是这个小了(在系统资源空闲的时候)。

3. 第一列的 * 或 root ,代表为所有用户或 root 用户设置这个配置。

4. 第二列的 soft 软规则限制, hard 硬规则限制, soft 指的是当前系统生效的设置值, hard 表明系统中所能设定的最大值,soft 的限制不能比 hard 限制高。

5. 65535 是设置的值,根据实际的需求和系统的配置去配置。

<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` 问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值