如何在Linux中配置限制 Linux ulimit临时与永久

答案是配置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系统里，配置

限制资源，说白了，就是给你的进程或者用户划定一个资源使用的上限。如果你只是想在当前会话里临时调整，那直接在shell里用命令就行，它会立刻生效，但一关掉终端或者退出会话就失效了。要是想让这个限制长久地、系统性地生效，那你就得去改这个配置文件，甚至可能还要动到Systemd的服务单元文件，这需要重启会话或者服务才能看到效果。

解决方案

要搞定

，我们通常会从两个维度入手：临时的会话级调整和永久的系统级配置。

先说临时配置，这个最简单直接。你打开一个终端，想看看当前会话有什么限制，敲个

就全出来了。比如，你发现默认的打开文件数（）是1024，这对于一些高并发的服务来说，简直就是个笑话。想临时提高？很简单，比如改成65535：

这里的

就是指文件描述符的数量（number of open files）。类似的，如果你想限制一个用户能启动的进程数（number of processes），可以用：

这些命令执行后，立刻在当前shell会话及其子进程中生效。你再跑个

，就能看到变化了。但切记，这玩意儿是“一次性”的，终端一关，或者你新开一个终端，这些设置就都没了，又回到系统默认值或者里定义的那些。

然后是永久配置，这才是我们日常运维里更常用的。核心文件是

。这个文件是PAM（Pluggable Authentication Modules）模块在用户登录时读取的。它的格式大致是这样的：

这里面的

可以是用户名、组名（前面加）、或者（代表所有非root用户）。有两种：（软限制）和（硬限制），我后面会详细解释。就是你要限制的项目，比如（文件描述符）、（进程数）、（core文件大小）等。就是具体的数值。

改完这个文件，你需要让用户登出再重新登录，或者重启相关服务，这些新的限制才能被PAM模块加载并应用。有时候，你可能还会发现

里的设置没生效，这往往和PAM的配置有关，需要确保或者这些文件里有这一行。这就像是告诉系统，登录的时候记得去看看。

但如果你的应用是作为Systemd服务运行的，比如Nginx、Redis这类，它们通常不是直接通过用户登录会话启动的，这时候

的优先级可能就不那么高了。对于Systemd服务，更直接、更可靠的方式是在它的单元文件里直接设置。

为什么我的ulimit设置没有生效？

这绝对是初学者和老手都可能踩的坑，我个人就遇到过不少。当你满心欢喜地改了配置，却发现

显示的值还是老样子，那种感觉真是让人抓狂。

首先，最常见的原因是你没有重新登录会话。

的设置是通过PAM模块在用户登录时读取并应用的。如果你只是改了文件，然后在一个已经打开的终端里跑命令，那自然看不到效果。你得完全登出当前用户，再重新登录。对于SSH会话，就是断开SSH连接再重新连上。

其次，PAM模块的配置可能不正确。就像我前面提到的，

必须在PAM配置文件中被引用。你可能需要检查、、等文件，确保其中包含类似的行。如果缺少了，系统就不知道要去加载里的限制。

再来，你可能在查看一个错误的上下文。比如，你为

用户设置了限制，但你却在用户的会话里查看，或者在另一个没有关联的用户会话里查看，那肯定是不对的。确保你是在目标用户身份下，或者目标服务进程的上下文下去验证。

还有一种情况是，Systemd服务单元文件中的限制覆盖了

。如果你的应用是以Systemd服务运行的，比如Nginx，即使你在里给用户设置了很高的文件描述符限制，但如果Nginx的Systemd服务文件（比如）里有这样的设置，那么服务启动时会优先采用Systemd的限制。这是Systemd自己的资源管理机制，优先级更高。

最后，要区分软限制（soft limit）和硬限制（hard limit）。你可能只看到了软限制，而没有注意到硬限制。一个进程的软限制不能超过其硬限制。如果你把软限制设置得很高，但硬限制却很低，那实际上能达到的上限还是硬限制。

ulimit中的hard limit和soft limit有什么区别？

这块儿挺有意思的，也是理解

机制的关键。简单来说，是当前实际生效的限制，而则是一个不可逾越的“天花板”。

软限制（Soft Limit）： 这个是你的进程当前实际能使用的资源上限。比如，

默认显示的就是软限制。一个进程可以自行调整自己的软限制，但它不能超过对应的硬限制。对于普通用户来说，他们可以降低自己的软限制，也可以在不超过硬限制的前提下提高它。比如，你当前软限制是1024，硬限制是65535，你可以用把软限制提高到2048，但不能直接提高到70000。

硬限制（Hard Limit）： 这个是系统管理员设定的一个绝对上限，是进程能够将软限制提升到的最大值。普通用户只能降低硬限制，不能提高它。只有

用户或者拥有相应权限的进程才能提高硬限制。它就像一道物理屏障，确保即使进程失控，也不会无限制地消耗系统资源。

在

文件中，我们通常会同时设置和两种限制。比如：

这意味着，所有非root用户默认的文件描述符软限制是65535，但他们最多可以把这个软限制提升到131070。这个设计很灵活，它允许用户在一定范围内根据需求调整资源，同时又保证了系统整体的稳定性。在我看来，硬限制是系统安全和资源保障的最后一道防线。

针对特定服务或Systemd单元如何设置ulimit？

对于那些作为后台服务运行的应用程序，特别是通过Systemd管理的服务，直接在Systemd单元文件里配置

是既清晰又可靠的做法。因为这些服务通常不是通过用户登录会话启动的，所以对它们的影响可能就没那么直接了。

Systemd提供了一系列

指令，可以直接在服务的文件里指定。这使得每个服务都能拥有自己独立的资源限制，而不会相互影响。

比如，你有一个Nginx服务，它需要打开大量文件（连接、日志等），你可以在Nginx的Systemd单元文件（通常在

或）的节中添加如下行：

这里的：

• LimitNOFILE=65536

  登录后复制
  ：设置了Nginx服务可以打开的最大文件描述符数量为65536。

• LimitNPROC=4096

  登录后复制
  ：限制了Nginx服务及其子进程可以创建的最大进程数为4096。

• LimitCORE=infinity

  登录后复制
  ：表示核心文件（core dump）的大小没有限制。如果你想限制它，可以给一个具体数值，比如

  LimitCORE=1G

  登录后复制
  。

当你修改了Systemd单元文件后，别忘了执行以下命令来让Systemd重新加载配置并重启服务：

这样，Nginx服务启动时就会直接使用这些在单元文件里定义的

值，而不会去管里对用户设置的全局限制。在我看来，这种方式为服务提供了更精细、更隔离的资源控制，非常适合生产环境中的关键应用。它避免了因为用户全局限制过低而导致服务启动失败，或者因为全局限制过高而让某个失控的服务消耗过多资源。

以上就是如何在Linux中配置限制 Linux ulimit临时与永久的详细内容，更多请关注php中文网其它相关文章！