
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Sun, 26 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/file-descriptor/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-07-26-linux-too-many-open-files</guid>
    <title>Too many open files 완전 해결 — ulimit을 올려도 안 되는 이유</title>
    <link>https://www.youngju.dev/blog/linux/2026-07-26-linux-too-many-open-files</link>
    <description>서버 로그에 accept4 failed (24: Too many open files)가 찍히고 ulimit -n을 올렸는데도 그대로입니다. 이 증상 뒤에는 서로 독립적인 세 가지 한계가 있습니다. 프로세스별 RLIMIT_NOFILE, 시스템 전역 fs.file-max, 그리고 systemd 서비스의 LimitNOFILE이 셸의 ulimit 설정을 완전히 무시한다는 사실입니다. /proc/PID/limits로 실제 적용값을 확인하는 법, fd를 소켓·파일·파이프로 세분해 무엇이 먹는지 찾는 법, inotify와 epoll은 별개의 한계라는 점, 그리고 진짜 원인인 fd 누수를 확인하는 법을 정리합니다.</description>
    <pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>systemd</category><category>file-descriptor</category><category>troubleshooting</category><category>containers</category>
  </item>

    </channel>
  </rss>
