• 热门搜索 热门搜索

您现在的位置是:博客 > 文章详情文章详情

解决:“The configured user limit (128) on the number of inotify instances has been reached....” 错误

原创
时间2024/01/30 17:53:12 发布 预览数量149
分类: linux 标签: linux 系统

一、场景再现

在linux系统上运行着10个微服务,突然发现某个服务挂了。遇到这种情况,一般就使用命令docker start 就可以解决。 然而发现命令无法使服务起来。根据跟踪容器日志发现是出现了异常,如下所示:

Unhandled exception. System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.
   at System.IO.FileSystemWatcher.StartRaisingEvents()
   at System.IO.FileSystemWatcher.StartRaisingEventsIfNotDisposed()
   at System.IO.FileSystemWatcher.set_EnableRaisingEvents(Boolean value)
   at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.TryEnableFileSystemWatcher()
   at Microsoft.Extensions.FileProviders.Physical.PhysicalFilesWatcher.CreateFileChangeToken(String filter)
   at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(String filter)
   at Microsoft.Extensions.Configuration.FileConfigurationProvider.<.ctor>b__1_0()
   at Microsoft.Extensions.Primitives.ChangeToken.OnChange(Func`1 changeTokenProducer, Action changeTokenConsumer)
   at Microsoft.Extensions.Configuration.FileConfigurationProvider..ctor(FileConfigurationSource source)
   at Microsoft.Extensions.Configuration.Json.JsonConfigurationSource.Build(IConfigurationBuilder builder)
   at Microsoft.Extensions.Configuration.ConfigurationManager.AddSource(IConfigurationSource source)
   at Microsoft.Extensions.Configuration.ConfigurationManager.Microsoft.Extensions.Configuration.IConfigurationBuilder.Add(IConfigurationSource source)
   at Microsoft.Extensions.Configuration.ConfigurationExtensions.Add[TSource](IConfigurationBuilder builder, Action`1 configureSource)
   at Microsoft.Extensions.Configuration.JsonConfigurationExtensions.AddJsonFile(IConfigurationBuilder builder, IFileProvider provider, String path, Boolean optional, Boolean reloadOnChange)

这个日志看不大懂,一开始我以为是有人提交的代码有问题, 所以我首先检查了相应的服务, 本地都是ok的,找了一圈都没找到问题所在。因为是测试环境,就选择了重启服务器(重启是万能的)。发现之前无法启动的服务起来了,但是另外一个服务业除了这个问题。我顿时觉得不是代码问题, 应该是Linux问题, 所以我就针对错误The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached进行了一番查阅, 最终找到了问题所在。

二、解决错误

这个错误信息通常表示你的应用程序已经达到了系统对 inotify 实例或打开文件描述符数量的限制。
Inotify 是一个 Linux 内核子系统,它允许应用程序监视文件系统的变化。

例如:文件或目录的创建、删除、修改等每个应用程序都有一个 inotify 实例数量的限制,这个限制通常在 /proc/sys/fs/inotify/max_user_instances 中设置同样,每个进程也有一个打开文件描述符数量的限制你可以在 /proc/sys/fs/file-max 中查看这个限制。

我们可以按照以下指令来解决这个问题:

echo 100000 > /proc/sys/fs/inotify/max_user_instances  
echo 200000 > /proc/sys/fs/file-max

但是这只是一个临时的解决方案,因为重启系统后这个设置将被重置。如果你想永久地改变这个设置,我们需要设置永久生效。
vim /etc/sysctl.conf 添加如下内容

fs.inotify.max_user_instances = 100000  
fs.file-max = 200000

然后运行 sysctl -p 来使新的设置生效。这样就可以永久的解决问题了。

版权声明:本文为Converts的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://www.converts.cn/article/7023045.html

暂无评论

暂无评论

目录

推荐阅读

  • Docker 部署FastTunnel,实现内网穿透

    ## 一、前言 最近在学习搭建**Elasticsearch**集群,但是发现云服务(2核4G)资源根本就不够用,部署上去就直接宕机了。想着服务器资源太贵, 家里刚好有一台**64G**内存的闲置电脑。不如做一个**内网穿透**,可以远程访问。工作学习两不误。其实目前市面上已经有很多穿透工具了,比如向日葵~~ ,但是奈何带宽太小了,免费的才1M~~~ ## 二、什么是 FastTunnel **FastTunnel** 是用.net core开发的一款跨平台内网穿透工具,它可以实现将内网服务暴露到公网供自己或任何人访问。 与其他穿透工具不同的是:FastTunnel项目致力于打造一个易于扩

  • 解决:“The configured user limit (128) on the number of inotify instances has been reached....” 错误

    ## 一、场景再现 在linux系统上运行着10个微服务,突然发现某个服务挂了。遇到这种情况,一般就使用命令`docker start` 就可以解决。 然而发现命令无法使服务起来。根据跟踪容器日志发现是出现了异常,如下所示: ```shell Unhandled exception. System.IO.IOException: The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open fi

  • Docker 安装mysql

    ## 一、创建mysql 容器 ```shell docker run \ -d \# 后台运行 --restart=always \#总是跟随docker启动 --privileged=true\#获取宿主机root权限 -p 13306:3306 --name mysql \# 容器与主机映射端口为,主机13306,容器3306 -v /mysql/log:/var/log/mysql \# 容器运行后的名称 -v /mysql/data:/var/lib/mysql \# mysql 目录挂载 -v /etc/localtime:/etc/localtime:ro \#让容器的时钟与宿主

  • validate service connection: CRI v1 runtime API is not implemented for endpoint \"unix:///var/run/containerd/containerd.sock\": rpc error: code = Unimplemented desc = unknown service runtime.v1.RuntimeService

    ## 一、问题 安装k8s集群, Node节点加入主节点的时候(`kubeadm join...`),报错,报错信息如下: ```shell [root@node1 ~]# kubeadm join k8s-master:6443 --token 4nm8cy.jgxw8go95c1uqt6c --discovery-token-ca-cert-hash sha256:f1c08bce4ebeb8deb531b950e644cca399efc40e1a9ac99df21b7b38a31a6c02 [preflight] Running pre-flight checks

  • k8s 安装ingress,并解决拉取镜像失败的问题

    ## 一、前言 Service 是将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法,但是Service 只能在内网间访问(NodePort方式用的较少), 那么外网的路由请求如何发送到 Service 上呢? k8s 为我们提供了 Ingress 网关服务。 ## 二、什么是Ingress ? Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例: ![k8s 安装ingress,并解决拉取镜像失败的问题](/Article

  • ssh 免密登录

    ## 一、前言 SSH(Secure Shell)免密登录是一种安全便捷的远程登录方式,允许用户在不输入密码的情况下连接到远程Linux服务器。它通过密钥认证来实现登录,这种方法可以提高工作效率,同时加强系统的安全性。 ## 二、秘钥的存放位置 一般秘钥都存放在用户的根目录下 `~/.ssh`,如下图所示 ![ssh 免密登录](/ArticleFile/2024-01-09/802cf3e23bde4298bf4accd9929878c6.png 'ssh 免密登录') .ssh 目录下一般会有两个文件 `id_rsa:私钥` 、 `id_rsa.pub:公钥`。 ![ssh 免密

  • k8s http: server gave HTTP response to HTTPS client

    ## 一、问题 k8s 在拉取私有仓库镜像的时候报`http: server gave HTTP response to HTTPS client`错,网络上的答案都是千篇一律的,根本就没有抓住问题的根源。下面就有我来剖析一下问题的原因。 ```shell Type Reason Age From Message ---- ------ ---- ---- ------- Normal Schedule

  • org.jenkinsci.plugins.scriptsecurity.scripts.UnapprovedUsageException: script not yet approved for use

    ## 一、报错信息 jenkins 中编写pipeline脚本的时候,执行构建,报如下错误: ```shell Started by user admin org.jenkinsci.plugins.scriptsecurity.scripts.UnapprovedUsageException: script not yet approved for use at org.jenkinsci.plugins.scriptsecurity.scripts.ScriptApproval.using(ScriptApproval.java:676) at org.jenkinsci.plugin

  • kubeadm init:failed to pull image registry.k8s.io/pause:3.6

    ## 一、错误现象 在安装 **K8s 1.28.0** 的时候,**kubeadm init...** 执行失败,错误信息如下: ```shell [kubelet-check] Initial timeout of 40s passed. Unfortunately, an error has occurred: timed out waiting for the condition This error is likely caused by: - The kubelet is not running - The kubelet is

  • .net core 通过环境变量加载配置文件(Development、Staging、Production)

    ## 一、前言 在**.net core 2.1** 之前,每次更新程序, 都需要手动更改数据库连接字符串。如果不小心把测试库发布上去了, 问题就大了。不过好在.NET Core 2.1及以上版本增加了支持根据环境变量加载配置文件。简单点理解就是, **代码中有三个配置文件(开发,测试,生产),程序发布之后, 更具服务器的环境变量, 自动加载相应的配置文件,不用在每次手动的切换了**。很是方便。 ## 二、实现 要想实现此功能,我们需要设置对应配置文件的后缀,以便系统会自动识别。 **举个例子:** 假设现在有一个叫 `Database.json` 的数据库配置文件,我们只需要再创建两个配

加载中