关于Linux报Resource temporarily unavailable问题解决记录

本文介绍了一次在Linux系统中因用户进程数限制导致的应用OOM问题。通过调整inmgr用户的进程数和文件描述符数量限制,成功解决了问题并避免了应用崩溃。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

 

事件记录

 解决方案


事件记录


由于今天需要在测试环境把应用从root用户迁移到inmgr用户,当时创建了inmgr用户就直接进行了迁移。5分钟后应用直接出现OOM异常,经过上网查实,新建用户Linux系统会限制用户的最大进程数。应用程序占满进程数过后,执行任何命令都会报:

/bin/bash: Resource temporarily unavailable。

新用户的进程数限制一般都是在1024或者2048。

 解决方案

现在以这台服务器为例:

  1.  使用root用户登陆,进入到/etc/security/limits.d/:
    [root@VM_3_220_centos ~]$ cd /etc/security/limits.d/
    [root@VM_3_220_centos limits.d]$ ll
    total 8
    -rw-r--r-- 1 root root 195 Aug 29  2017 20-nproc.conf
    -rw-r--r-- 1 root root  60 Apr 21  2016 80-nofile.conf

     

  2. 编辑20-nproc.conf:

    [root@VM_3_220_centos limits.d]$ vim 20-nproc.conf 

     

  3. 添加以下信息:

    inmgr      soft    nproc     60000

    添加后的文件内容应该为:

    # Default limit for number of user's processes to prevent
    # accidental fork bombs.
    # See rhbz #432903 for reasoning.
    
    *          soft    nproc     4096
    root       soft    nproc     unlimited
    inmgr      soft    nproc     60000

     

  4. 编辑/etc/security/limits.conf,添加以下内容:

    inmgr soft nproc 60000
    inmgr hard nproc 65535
    inmgr soft nofile 60000
    inmgr hard bofile 65535

    编辑后的文件内容为:

    # End of file
    * soft nofile 100001
    * hard nofile 100002
    root soft nofile 100001
    root hard nofile 100002
    inmgr soft nproc 65535
    inmgr hard nproc 65535
    inmgr soft nofile 60000
    inmgr hard nofile 65535

    nproc:表示max number of processes
    nofile:表示max number of open file descriptors
    hard/soft:soft是一个警告值,而hard则是一个真正意义的阀值,超过就会报错。

  5. 再次切换到inmgr用户,执行ulimit -a

    [inmgr@VM_3_220_centos ~]$ ulimit -a
    core file size          (blocks, -c) 0
    data seg size           (kbytes, -d) unlimited
    scheduling priority             (-e) 0
    file size               (blocks, -f) unlimited
    pending signals                 (-i) 7271
    max locked memory       (kbytes, -l) 64
    max memory size         (kbytes, -m) unlimited
    open files                      (-n) 65535
    pipe size            (512 bytes, -p) 8
    POSIX message queues     (bytes, -q) 819200
    real-time priority              (-r) 0
    stack size              (kbytes, -s) 8192
    cpu time               (seconds, -t) unlimited
    max user processes              (-u) 65535
    virtual memory          (kbytes, -v) unlimited
    file locks                      (-x) unlimited

    可以看到最大进程数已经修改为65535了。重启应用后没有出现OOM异常。 

     

     

     

<think>嗯,用户问的是关于Linux中出现的“Resource temporarily unavailable”错误提示,需要我详细介绍一下。首先,我应该回忆一下这个错误通常出现在什么情况下。记得这个错误对应的错误代码是EAGAIN,有时候也可能显示为EWOULDBLOCK,不过在Linux上这两个通常是一样的。 接下来,我需要确定这个错误发生的常见场景。比如,当进程试图进行非阻塞操作,但资源不可用时就会返回这个错误。例如,使用非阻塞的I/O操作时,如果没有数据可读或者缓冲区已满,就会遇到这个问题。这时候程序应该等待并重试,或者处理其他任务。 另外,多线程或多进程环境中,如果达到了系统资源限制,比如打开文件数、进程数、内存分配等,也会导致这个错误。例如,用户可能用完了文件描述符,或者在fork时超过了进程数限制,这时候需要检查ulimit的设置。 还有,信号处理也可能引发这个问题。比如,在执行某些系统调用时,如果被信号中断,可能会返回EAGAIN,要求重新执行调用。这时候可能需要检查errno并重试。 然后,我需要考虑用户可能的背景。他们可能是在开发过程中遇到了这个错误,或者在运行某个程序时突然出现。可能需要给出具体的例子,比如socket编程中的非阻塞模式,或者文件操作时的资源限制。 用户可能需要知道如何诊断这个问题,比如使用strace跟踪系统调用,或者检查ulimit的当前设置。解决方法可能包括调整资源限制、修改代码处理EAGAIN错误、或者优化资源使用。 还需要注意区分不同的情况,比如资源耗尽和暂时不可用。如果是资源耗尽,可能需要增加系统限制;如果是非阻塞操作,需要在代码中添加重试逻辑。 最后,要确保解释清晰,步骤明确,让用户能够根据指导自行排查和解决问题。可能需要给出示例命令,如ulimit -n,或者代码片段处理EAGAIN的情况。</think>**Linux 提示 "Resource temporarily unavailable" 的常见原因与解决方法** 在 Linux 系统中,**"Resource temporarily unavailable"** 是一个常见的错误提示(对应错误码 `EAGAIN` 或 `EWOULDBLOCK`),通常与**系统资源分配或非阻塞操作**相关。以下是其常见场景和解决方案: --- ### **1. 非阻塞 I/O 操作未就绪** - **场景**:当程序使用**非阻塞模式**(如 `O_NONBLOCK` 标志)操作文件、套接字或管道时,若资源未准备好(如无数据可读、缓冲区已满),会直接返回此错误。 - **解决方法**: - **循环重试**:在代码中捕获错误并重试操作(需设置合理超时,避免死循环)。 - **使用 I/O 多路复用**:通过 `select()`, `poll()`, 或 `epoll()` 监控资源状态,等待就绪后再操作。 **示例代码(非阻塞读重试)**: ```c while (1) { n = read(fd, buf, size); if (n >= 0) break; // 成功读取 if (errno != EAGAIN) { /* 处理其他错误 */ } usleep(retry_delay); // 等待后重试 } ``` --- ### **2. 系统资源达到限制** - **场景**:当进程尝试创建新线程、打开文件、分配内存等操作时,若超过系统或用户级资源限制(如 `ulimit` 设置),会触发此错误。 - **常见资源限制**: - **进程/线程数**:`ulimit -u`(用户最大进程数) - **文件描述符数**:`ulimit -n`(单个进程最大打开文件数) - **内存限制**:`ulimit -m`(物理内存)、`ulimit -v`(虚拟内存) - **解决方法**: 1. **临时调整限制**: ```bash ulimit -n 65535 # 修改文件描述符数(仅当前会话有效) ``` 2. **永久修改限制**:编辑 `/etc/security/limits.conf`,例如: ``` * soft nofile 65535 * hard nofile 65535 ``` 3. **检查程序资源泄漏**:使用 `lsof` 或 `ps` 分析进程资源占用。 --- ### **3. 信号中断系统调用** - **场景**:若进程在执行阻塞式系统调用(如 `read()`, `accept()`)时被信号(Signal)中断,可能返回 `EAGAIN`。 - **解决方法**:在代码中自动重试被中断的系统调用。 ```c retry: n = accept(sockfd, addr, addrlen); if (n < 0 && errno == EINTR) goto retry; // 信号中断后重试 ``` --- ### **4. 其他场景** - **磁盘空间不足**:写入文件时若磁盘满,可能触发此错误(需清理磁盘或扩容)。 - **网络拥塞**:发送大数据包时若缓冲区满,需等待或调整 TCP 窗口大小。 - **高并发竞争**:多线程/进程竞争共享资源时,需优化锁机制或资源分配策略。 --- ### **诊断工具** - **`strace`**:跟踪系统调用,定位触发错误的操作: ```bash strace -e trace=file,network -p <PID> ``` - **`dmesg`**:查看内核日志,检查是否有资源耗尽记录。 - **`lsof`**:列出进程打开的文件描述符: ```bash lsof -p <PID> ``` --- ### **总结** 遇到 "Resource temporarily unavailable" 时,首先需明确触发场景: - **非阻塞操作** → 添加重试逻辑或 I/O 多路复用。 - **资源不足** → 调整系统限制或优化程序。 - **信号中断** → 在代码中处理 `EINTR` 错误。 通过合理设计代码和调整系统配置,可以有效规避此问题
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值