在CentOS 7系统里，若想为单个用户设定CPU和内存的限制，可通过编辑/etc/security/limits.conf文件来实现。具体操作如下：在文件中添加“username soft cpu 300、hard cpu 600（单位为秒/分钟）”，这是对CPU的限制设定；再添加“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 —— 这是验证是否真正起效的关键信号。
为什么 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等系统路径做递归权限变更
资源分配的本质不是开放，而是划定边界。越老的硬件、越简陋的部署环境，越要靠精确的限制来换取整体稳定 —— 宽松从来不是兼容性的解药，只是延迟崩溃的麻醉剂。
