在CentOS 7中，可通过编辑/etc/security/limits.conf为单个用户设置CPU和内存限制：添加username soft cpu 300、hard cpu 600（单位秒/分钟），soft memlock 512000、hard memlock 1024000（KB），soft as 1048576、hard as 2097152（字节）；需确保PAM启用pam_limits.so，且用户重新登录生效。
如何用 ulimit 限制单个用户的 CPU 和内存资源
CentOS 7 默认不限制用户进程的资源用量，老旧机器或多人共用环境里，一个 runaway 进程就可能吃光内存、拖垮系统。直接改 /etc/security/limits.conf 是最常用也最有效的入口。
常见错误是只写用户名，却没配生效范围（比如漏掉 - soft nproc 1024 导致 fork 失败但无提示），或改完没重启登录会话。
- 编辑
/etc/security/limits.conf，追加（不是覆盖）：
username soft cpu 300 username hard cpu 600 username soft memlock 512000 username hard memlock 1024000 username soft as 1048576 username hard as 2097152
cpu 单位是秒/分钟，memlock 是 KB，as 是虚拟内存字节数（即 RLIMIT_AS）。注意：soft 可被用户临时提升（不超过 hard），hard 只能 root 修改。
- 确保 PAM 模块已启用：检查
/etc/pam.d/login或/etc/pam.d/sshd是否含session required pam_limits.so；若缺失，手动添加一行 - 普通用户需重新登录才生效（
su - username不触发 limits，必须完整会话）
怎样给用户分配指定磁盘配额（quota）
配额不是“给目录赋权”，而是对挂载点上所有属于该用户的文件块和 inode 总量设上限。它依赖 ext4 文件系统支持，且必须在挂载时启用 usrquota。
典型翻车点：改了 /etc/fstab 但忘记 mount -o remount /，或运行 quotacheck 前没先关掉所有该挂载点上的写入进程（否则生成的 aquota.user 会不准确）。
- 确认根分区使用 ext4：
tune2fs -l /dev/sda1 | grep "Filesystem features"，输出含has_journal即可 - 修改
/etc/fstab对应行，末尾加,usrquota,grpquota（注意逗号不空格） - 执行
mount -o remount /，再运行quotacheck -cum /（-c初始化，-u用户，-m不校验已挂载状态） - 启用：
quotaon /；查看：quota -u username
配额生效后，用户 dd if=/dev/zero of=test.img bs=1M count=2000 超过硬限制会报 Disk quota exceeded，而非 No space left on device —— 这是验证是否真正起效的关键信号。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
为什么 systemd 的 ResourceLimit 在 CentOS 7 上基本不可用
CentOS 7 自带的 systemd 版本是 219，而 MemoryLimit、CPUQuota 等资源控制项在 systemd 229+ 才稳定支持 cgroup v2，且默认仍用 cgroup v1。强行在 .service 文件里写 MemoryLimit=512M 会被忽略，日志里也不会报错，只默默失效。
这不是配置问题，是版本硬伤。想用 systemd 做细粒度资源隔离，必须升级 systemd（不推荐）或换发行版（如 CentOS 8 Stream 或 Rocky 8+）。
- 验证方式：
systemctl show --property=CPUQuota some.service返回CPUQuota=（空值）即未识别 - 替代方案：用
cgrulesengd+cgconfig配置 cgroup v1 规则（需装libcgroup-tools），但维护成本高，仅建议对关键服务（如数据库）做单点控制
哪些权限分配操作会意外破坏系统稳定性
给用户加权限最容易踩的坑，不是“不够用”，而是“太宽泛”。比如 chmod -R 777 /home/xxx 看似方便，但若该目录下有 .ssh 或 .bashrc，SSH 会拒绝登录（私钥权限太宽松），shell 启动也可能失败。
更隐蔽的是 SELinux 上下文错乱：用 chown -R 或 cp -r 移动文件后，SELinux 标签不会自动更新，导致服务（如 httpd、vsftpd）无法读取本该有权访问的文件，报错却是 Permission denied 而非 SELinux 相关字样。
- 安全底线：永远不用
777，对 web 目录用755/644，上传目录用755+setgid保证组继承 - 修复 SELinux：
restorecon -Rv /path/to/dir（比chcon更可靠） - 禁止对
/etc、/var/log、/boot等系统路径做递归权限变更
资源分配的本质不是开放，而是划定边界。越老的硬件、越简陋的部署环境，越要靠精确的限制来换取整体稳定 —— 宽松从来不是兼容性的解药，只是延迟崩溃的麻醉剂。
