答案是配置ulimit需区分临时与永久方式，临时用ulimit命令调整会话级限制，永久则修改limits.conf或Systemd服务文件。临时设置如ulimit -n 65535立即生效但重启失效；永久生效需在/etc/security/limits.conf中为用户或组设置soft/hard限制，并确保pam_limits.so加载；对于Systemd服务，应在.service文件中使用LimitNOFILE等参数定义，再执行systemctl daemon-reload和restart服务生效。常见问题包括未重新登录、PAM配置缺失、Systemd覆盖limits.conf及混淆soft与hard limit，其中hard limit为上限，soft limit可在此范围内调整。
在Linux系统里，配置
ulimit
限制资源，说白了，就是给你的进程或者用户划定一个资源使用的上限。如果你只是想在当前会话里临时调整，那直接在shell里用
ulimit
命令就行，它会立刻生效，但一关掉终端或者退出会话就失效了。要是想让这个限制长久地、系统性地生效，那你就得去改
limits.conf
这个配置文件，甚至可能还要动到Systemd的服务单元文件，这需要重启会话或者服务才能看到效果。
解决方案
要搞定
ulimit
，我们通常会从两个维度入手：临时的会话级调整和永久的系统级配置。
先说临时配置，这个最简单直接。你打开一个终端，想看看当前会话有什么限制，敲个
ulimit -a
就全出来了。比如，你发现默认的打开文件数（
open files
）是1024，这对于一些高并发的服务来说，简直就是个笑话。想临时提高？很简单，比如改成65535：
ulimit -n 65535
这里的
-n
就是指文件描述符的数量（number of open files）。类似的，如果你想限制一个用户能启动的进程数（number of processes），可以用
-u
：
ulimit -u 4096
这些命令执行后，立刻在当前shell会话及其子进程中生效。你再跑个
ulimit -a
，就能看到变化了。但切记，这玩意儿是“一次性”的，终端一关，或者你新开一个终端，这些设置就都没了，又回到系统默认值或者
/etc/security/limits.conf
里定义的那些。
然后是永久配置，这才是我们日常运维里更常用的。核心文件是
/etc/security/limits.conf
。这个文件是PAM（Pluggable Authentication Modules）模块
pam_limits.so
在用户登录时读取的。它的格式大致是这样的：
# # * means all users except root* soft nofile 65535* hard nofile 131070# @developers group can open more files@developers soft nofile 100000@developers hard nofile 200000# specific user 'nginx'nginx soft nofile 65535nginx hard nofile 65535
这里面的
domain
可以是用户名、组名（前面加
@
）、或者
*
（代表所有非root用户）。
type
有两种：
soft
（软限制）和
hard
（硬限制），我后面会详细解释。
item
就是你要限制的项目，比如
nofile
（文件描述符）、
nproc
（进程数）、
core
（core文件大小）等。
value
就是具体的数值。
改完这个文件，你需要让用户登出再重新登录，或者重启相关服务，这些新的限制才能被PAM模块加载并应用。有时候，你可能还会发现
limits.conf
里的设置没生效，这往往和PAM的配置有关，需要确保
/etc/pam.d/common-session
或者
/etc/pam.d/login
这些文件里有
session required pam_limits.so
这一行。这就像是告诉系统，登录的时候记得去看看
limits.conf
。
但如果你的应用是作为Systemd服务运行的，比如Nginx、Redis这类，它们通常不是直接通过用户登录会话启动的，这时候
limits.conf
的优先级可能就不那么高了。对于Systemd服务，更直接、更可靠的方式是在它的
.service
单元文件里直接设置。
为什么我的ulimit设置没有生效？
这绝对是初学者和老手都可能踩的坑，我个人就遇到过不少。当你满心欢喜地改了配置，却发现
ulimit -a
显示的值还是老样子，那种感觉真是让人抓狂。
首先，最常见的原因是你没有重新登录会话。
limits.conf
的设置是通过PAM模块在用户登录时读取并应用的。如果你只是改了文件，然后在一个已经打开的终端里跑命令，那自然看不到效果。你得完全登出当前用户，再重新登录。对于SSH会话，就是断开SSH连接再重新连上。
其次，PAM模块的配置可能不正确。就像我前面提到的，
pam_limits.so
必须在PAM配置文件中被引用。你可能需要检查
/etc/pam.d/common-session
、
/etc/pam.d/login
、
/etc/pam.d/sshd
等文件，确保其中包含类似
session required pam_limits.so
的行。如果缺少了，系统就不知道要去加载
limits.conf
里的限制。
再来，你可能在查看一个错误的上下文。比如，你为
nginx
用户设置了
nofile
限制，但你却在
root
用户的会话里查看，或者在另一个没有关联的用户会话里查看，那肯定是不对的。确保你是在目标用户身份下，或者目标服务进程的上下文下去验证。
Midjourney
当前最火的AI绘图生成工具，可以根据文本提示生成华丽的视觉图片。
454 查看详情 
还有一种情况是，Systemd服务单元文件中的限制覆盖了
limits.conf
。如果你的应用是以Systemd服务运行的，比如Nginx，即使你在
limits.conf
里给
nginx
用户设置了很高的文件描述符限制，但如果Nginx的Systemd服务文件（比如
/etc/systemd/system/nginx.service
）里有
LimitNOFILE=1024
这样的设置，那么服务启动时会优先采用Systemd的限制。这是Systemd自己的资源管理机制，优先级更高。
最后，要区分软限制（soft limit）和硬限制（hard limit）。你可能只看到了软限制，而没有注意到硬限制。一个进程的软限制不能超过其硬限制。如果你把软限制设置得很高，但硬限制却很低，那实际上能达到的上限还是硬限制。
ulimit中的hard limit和soft limit有什么区别？
这块儿挺有意思的，也是理解
ulimit
机制的关键。简单来说，
soft limit
是当前实际生效的限制，而
hard limit
则是一个不可逾越的“天花板”。
软限制（Soft Limit）：这个是你的进程当前实际能使用的资源上限。比如，
ulimit -n
默认显示的就是软限制。一个进程可以自行调整自己的软限制，但它不能超过对应的硬限制。对于普通用户来说，他们可以降低自己的软限制，也可以在不超过硬限制的前提下提高它。比如，你当前软限制是1024，硬限制是65535，你可以用
ulimit -n 2048
把软限制提高到2048，但不能直接提高到70000。
硬限制（Hard Limit）：这个是系统管理员设定的一个绝对上限，是进程能够将软限制提升到的最大值。普通用户只能降低硬限制，不能提高它。只有
root
用户或者拥有相应权限的进程才能提高硬限制。它就像一道物理屏障，确保即使进程失控，也不会无限制地消耗系统资源。
在
/etc/security/limits.conf
文件中，我们通常会同时设置
soft
和
hard
两种限制。比如：
* soft nofile 65535* hard nofile 131070
这意味着，所有非root用户默认的文件描述符软限制是65535，但他们最多可以把这个软限制提升到131070。这个设计很灵活，它允许用户在一定范围内根据需求调整资源，同时又保证了系统整体的稳定性。在我看来，硬限制是系统安全和资源保障的最后一道防线。
针对特定服务或Systemd单元如何设置ulimit？
对于那些作为后台服务运行的应用程序，特别是通过Systemd管理的服务，直接在Systemd单元文件里配置
ulimit
是既清晰又可靠的做法。因为这些服务通常不是通过用户登录会话启动的，所以
/etc/security/limits.conf
对它们的影响可能就没那么直接了。
Systemd提供了一系列
Limit*
指令，可以直接在服务的
.service
文件里指定。这使得每个服务都能拥有自己独立的资源限制，而不会相互影响。
比如，你有一个Nginx服务，它需要打开大量文件（连接、日志等），你可以在Nginx的Systemd单元文件（通常在
/etc/systemd/system/nginx.service
或
/lib/systemd/system/nginx.service
）的
[Service]
节中添加如下行：
[Service]ExecStart=/usr/sbin/nginx -g "daemon on; master_process on;"# ... 其他配置 ...LimitNOFILE=65536LimitNPROC=4096LimitCORE=infinity
这里的：
LimitNOFILE=65536
：设置了Nginx服务可以打开的最大文件描述符数量为65536。
LimitNPROC=4096
：限制了Nginx服务及其子进程可以创建的最大进程数为4096。
LimitCORE=infinity
：表示核心文件（core dump）的大小没有限制。如果你想限制它，可以给一个具体数值，比如
LimitCORE=1G
。
当你修改了Systemd单元文件后，别忘了执行以下命令来让Systemd重新加载配置并重启服务：
sudo systemctl daemon-reloadsudo systemctl restart nginx
这样，Nginx服务启动时就会直接使用这些在单元文件里定义的
ulimit
值，而不会去管
limits.conf
里对
nginx
用户设置的全局限制。在我看来，这种方式为服务提供了更精细、更隔离的资源控制，非常适合生产环境中的关键应用。它避免了因为用户全局限制过低而导致服务启动失败，或者因为全局限制过高而让某个失控的服务消耗过多资源。
以上就是如何在Linux中配置限制 Linux ulimit临时与永久的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/936780.html
微信扫一扫 
支付宝扫一扫 
