1. 为什么文件描述符值得单独写一篇1.1 一句shell命令引发的血案很多人在Linux上干活干了好几年shell命令敲得飞起、、21这些随手就来但一旦遇到点奇怪现象就容易懵。比如下面这几行你看出区别了吗nohup java -jar app.jar /dev/null 21 nohup java -jar app.jar 21 /dev/null 第一行是大家常见的写法日志全丢进黑洞错误也一起丢进去。第二行看起来差不多只是把21挪到了前面但实际行为完全不一样——标准错误还是会打到终端上。为什么会这样因为重定向的解析是有顺序的而这个顺序就是围绕文件描述符展开的。再比如有人写脚本时发现明明程序里fprintf(stderr, ...)打印了错误但用./app log.txt跑的时候终端上还是能看到错误信息日志文件里却干干净净。这其实不是程序的问题而是标准错误fd 2没有被重定向它仍然指向终端。这些现象背后的统一解释就是文件描述符。搞懂它你就不需要背各种玄学命令组合而是可以自己推导出结果。这也是我写这篇的初衷——把文件描述符和重定向这条线彻底讲透让读者从会用变成懂得为什么这么用。1.2 文件描述符的本质内核里的一个数字编号文件描述符file descriptor简称fd从C语言的角度看就是一个int从内核的角度看是一个数组下标。每个进程在运行时内核会为它维护一张文件描述符表这张表的每一项指向内核中一个打开文件描述的结构体。你写的int fd open(test.txt, O_WRONLY);拿到的fd就是这张表的下标。所以当你执行printf(hello)时libc会把这个字符串通过write(1, hello, 5)写出去这里的1就是标准输出的文件描述符。shell里的重定向本质上是shell先open了目标文件拿到一个新fd然后通过dup2把fd 1复制成指向那个文件的fd之后再exec启动你的程序你的程序从头到尾不知道发生了什么它只管往fd 1上写但fd 1已经指向文件了。这个模型是所有重定向、管道、网络socket、磁盘IO的统一底层。理解了这个重定向那些符号就不再是记忆负担而是一套可以推导的规则。后面的内容都是围绕这个模型展开。2. 从shell重定向入手先搞清楚0、1、2的来龙去脉2.1 标准输入、标准输出、标准错误的默认绑定每个进程启动时内核默认给它开了三个fdfd名称默认指向C语言标准库0stdin标准输入终端键盘scanf、fread1stdout标准输出终端屏幕printf、fwrite2stderr标准错误终端屏幕fprintf(stderr, ...)注意stdout和stderr默认都指向终端但这俩是独立的fd。这也是为什么 log.txt只重定向stdout、stderr仍然打屏的原因。这里有个很多人忽略的细节默认情况下fd 0、1、2都指向同一个终端设备文件比如/dev/pts/3。虽然都指向同一个文件但它们是三个独立的fd表项各自有文件偏移。如果你在程序里先read(0, ...)读了几字节再lseek(0, 0, SEEK_SET)并不会影响fd 1的偏移因为fd 0和fd 1是两个不同的文件表项。不过有个特殊情况需要注意如果你用dup2把fd 1复制成fd 2比如执行21这时候fd 1和fd 2会指向同一个文件表项它们的文件偏移就共享了。这个区别在后续排查问题时很关键后面第5章会展开讲。2.2 重定向的四种基本形态shell重定向说到底就四种操作覆盖、追加、读入、拼接fd。我们逐个看。覆盖输出echo hello file.txtshell的内部动作是先open(file.txt, O_WRONLY | O_CREAT | O_TRUNC, 0644)拿到一个fd然后用dup2(fd, 1)把fd 1指向它最后关闭原来的fd。O_TRUNC表示如果文件已存在就清空。追加输出echo hello file.txt唯一的区别是open时用了O_APPEND标志每次写入时内核会把文件偏移挪到文件末尾而不是从头写。所以即使两个进程同时往同一个文件追加也不会互相覆盖在单机文件系统上O_APPEND的原子性是内核保证的。输入重定向cat file.txt对应open(file.txt, O_RDONLY)然后dup2(fd, 0)。cat从fd 0读实际是从文件读。拼接fd./app 21这里的21并不是把fd 2的内容复制给fd 1恰恰相反它表示把fd 2变成fd 1的复制品即让fd 2指向fd 1当前指向的那个文件对象。你可以从右往左读2要变成1的样子。在这里是取地址符号表示引用fd 1本身而不是创建一个名为1的文件。这种语法初学者容易搞混。我推荐一个记法AB就是把fd A指向fd B当前所指的地方。所以21是fd 2指向fd 1当前的目标12是fd 1指向fd 2当前的目标。理解了这一点后面所有顺序问题都能推导。2.3 顺序问题的坑21 与 file 谁先执行回到开头那段命令# 正确错误也进黑洞 nohup java -jar app.jar /dev/null 21 # 错误错误还是打屏 nohup java -jar app.jar 21 /dev/null 从左到右逐条解析这就是shell的规则。第一条先 /dev/nullfd 1指向/dev/null然后21fd 2指向fd 1当前的目标也就是/dev/null。两条都进了黑洞。第二条先21此时fd 1还指向终端所以fd 2变成了指向终端。然后 /dev/nullfd 1指向/dev/null。但fd 2仍然指向终端。于是错误信息照常打屏。这是文件描述符重定向最经典的坑面试也常考。我实际排查过不少线上日志丢失的问题根因都是这类顺序写反了。比如有人写./backup.sh backup.log 21这个是对的。但如果写成了./backup.sh 21 backup.log你会发现backup.log里只有stdoutstderr全丢了。排查思路就是拆开一步步看21先把stderr指向当前stdout终端接着 backup.log把stdout指向日志文件stderr还留在终端上。还有一个常见变体是管道符号。./app 21 | grep error和./app 21 | grep error本质上一样都是把stderr合并进stdout再进管道。但如果你写./app | grep error那么stderr不会进管道grep只会匹配到stdout错误信息直接打屏。很多人想在管道里过滤错误却过滤不到原因就在这里。如果你想明确把stderr和stdout分别送到不同的地方可以用31 1file 21这种骚操作先备份fd 1再重新规划这个属于进阶技巧后面章节会用到。3. 文件描述符的分配规则与生命周期3.1 为什么新fd总是从最小的空闲编号开始很多人观察到一个现象在shell里先exec 3temp.txt然后echo $$看看自己shell的pid再ls -l /proc/$$/fd发现新打开的fd是3。为什么不是5、不是10因为内核分配fd时总是从当前进程fd表中最小的空闲编号开始寻找。这个规则有个实际影响当你关闭fd 0后再打开一个新文件它拿到的编号会是0。很多守护进程在启动时会故意关闭stdin然后打开/dev/null并dup2到0目的就是确保后面打开文件时不会误占标准输入的位置。具体到编程里这个规则有个著名的坑int fd open(a.txt, O_RDONLY); // 假设拿到的fd是3 close(STDIN_FILENO); // 关闭0 int fd2 open(b.txt, O_RDONLY); // 此时fd2会拿到0而不是4如果你在close(0)之后继续用scanfscanf会从fd 0读而fd 0已经指向了b.txt行为完全变了。这类问题在长时间运行的daemon里很隐蔽。所以规范做法是不要随便close标准fd如果确实要关闭应该立刻把/dev/null dup2过去占位。3.2 fd的打开、关闭、复制从C语言角度看fd的生命周期就三个核心系统调用open、close、dup2。#include fcntl.h #include unistd.h int main() { int fd open(/tmp/test.log, O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd 0) { perror(open); return 1; } // 把fd 1重定向到这个文件 if (dup2(fd, STDOUT_FILENO) 0) { perror(dup2); return 1; } // 原始fd已经不需要了关掉 close(fd); printf(这条消息会写到 /tmp/test.log 里\n); return 0; }这里的关键是dup2它把fd 1变成fd的副本两个fd共享同一个文件表项共享文件偏移。调用完dup2之后fd和fd 1都能操作同一个文件但fd 1上的写入会改变共享偏移fd上读到的位置也会跟着变。开发中要特别留意dup2之后一定要及时close原始fd。如果不关闭fd表里就残留一个多余的fd指向同一个文件。在写程序时这不会造成问题但如果程序要长期运行每次循环都打开文件但不关闭fd就会越积越多最终达到进程的fd上限通常ulimit -n是1024后续open就会报Too many open files。顺便说一句dup和dup2的区别dup返回一个当前最小的空闲fd作为副本dup2则指定目标fd编号如果目标fd已经打开会先自动关闭再复制。shell里的21调用的就是dup2。3.3 文件描述符泄漏是怎么回事文件描述符泄漏这个说法更准确说应该是fd表项泄漏或打开文件描述泄漏——程序用完fd之后没有close导致这个fd一直占着一个表项。看一个典型的泄漏场景import os for i in range(100000): fd os.open(/dev/null, os.O_RDONLY) # 忘记调用 os.close(fd)跑一段时间后进程的fd数会到1024或更高取决于ulimit然后open开始返回EMFILEToo many open files。对于Python这种带垃圾回收的语言fd对象可能被GC回收时自动close但如果你用的是C或C泄漏就是实打实的。线上服务最常见的问题其实是fork之后没关fd父进程打开了数据库连接fd 3fork出子进程执行外部命令子进程继承了这个fd但它不会用也不关外部命令exec时这个fd还被带着如果父进程频繁fork短期内不会有问题但子进程如果把fd泄漏给孙进程一层层传递fd数量就可能爆掉。正确的做法是在fork之后、exec之前把子进程里不需要的fd全部关掉或者加上O_CLOEXEC标志。用open时指定O_CLOEXEC内核会在exec时自动关闭这个fd省去手动关闭的麻烦。排查fd泄漏时我一般先看ls /proc/PID/fd | wc -l如果数量持续上涨然后用lsof -p PID定位具体是哪些文件句柄没关。这个排查手法在第6章会详细说。4. 实战守护进程、nohup和日志重定向的常见坑4.1 nohup 与 之间的区别这两个东西经常被放在一起用但它们是两码事把进程放到后台执行。shell不等待它结束就返回提示符但进程的stdin/stdout/stderr仍然连接着终端。nohup忽略SIGHUP信号。当终端关闭时内核会向终端的前台进程组发送SIGHUP普通进程收到这个信号的默认动作是退出。nohup让进程忽略这个信号所以即使关了终端它也能继续跑。配合使用时shell通常会自动把stdin重定向到/dev/null某些shell的行为但stdout和stderr需要你自己处理。如果既不用nohup也不重定向输出后台进程输出到已关闭的终端fd时会收到SIGPIPE信号默认行为也是自杀。所以网上教程一律推荐nohup command /dev/null 21 这个组合能保证进程不因SIGHUP退出、不因SIGPIPE退出、不因输出占满终端而被打断。但如果你想让日志持久保存应该把/dev/null换成实际日志路径并且用追加而不是覆盖防止多次重启把历史日志冲掉nohup ./app /var/log/app.out 21 4.2 后台任务关闭终端后fd发生了什么有个场景我遇到过不止一次用SSH登录服务器跑了个训练任务用放到后台然后直接关掉SSH窗口。过几分钟重新登录一看进程没了日志停在半路。为什么因为你关掉SSH窗口后SSH服务端会关闭这个会话对应的pts设备进程的fd 1和fd 2指向的pts文件就失效了。进程往一个已经失效的终端文件写数据会触发写入错误。如果程序不检查write返回值可能继续跑但如果它用的是stdio缓冲缓冲区写不出去可能触发SIGPIPE进程就死了。另外SIGHUP信号也会直接把进程杀掉。解决办法就是上面那套nohup ... logfile 21 。它的本质就是让fd 1和fd 2不再指向终端而是指向普通文件这样终端关闭与否就跟进程无关了。更彻底的做法是用setsid启动一个新会话setsid ./app /var/log/app.out 21 /dev/null setsid让进程脱离原会话不再有控制终端这样连终端的SIGHUP、SIGTTOU等一系列信号都收不到了。用systemd管理服务时本质上也包含了这些隔离逻辑。4.3 一个真实案例Java应用日志丢失去年帮朋友排查一个Java应用的问题他用nohup java -jar app.jar app.log 21 启动跑了几天后看日志发现中间有整整两天没有日志但进程一直在服务也正常响应请求。排查过程是这样的先用ls -l /proc/PID/fd/1看stdout指向哪里发现它确实指向app.log已被删除。再用lsof -p PID | grep deleted确认发现fd 1指向的文件已经被删除了但进程没有重新打开文件内核里保留的还是一个指向已删除文件的inode。也就是说有人或者logrotate把这个日志文件rotate走了文件名变了或者文件被删了但Java进程不知道仍然往旧inode写数据。于是日志写进了已经被删除的文件里既看不到还占了磁盘空间直到进程释放fd才回收。这个问题在运维中非常常见。解决办法有几种在logrotate配置里加copytruncate先复制再清空原文件这样进程持有的fd仍然指向同一个inode能继续写入。应用层面用支持按日期滚动的日志库自己管文件打开和切换。或者用cron定期kill -HUP让程序重新打开日志文件前提是程序实现了SIGHUP处理。从这个案例能看出理解fd的底层逻辑不只是应付面试排查这种日志神秘消失的问题时非常有用。fd指向的是inode而不是文件名这个认知误区是很多日志丢失问题的根源。5. 内核视角fd表、文件表与inode之间的三角关系5.1 为什么要分三层很多资料会画一张三层结构图进程fd表 - 系统级打开文件表 - inode。画图是为了方便理解我这里用文字把它讲清楚因为光看图容易忽略层与层之间的语义差异。第一层进程级fd表。每个进程一张数组结构下标就是fd。表中每个表项指向第二层的一个文件对象。当你open一个文件时不是直接关联inode而是先创建一个打开文件描述符对象然后fd表项指向它。第二层系统级打开文件表。全局共享每个表项包含文件偏移当前读写位置、访问模式只读/只写/读写、状态标志O_APPEND、O_NONBLOCK等、以及指向inode的指针。这层可以理解为一次open产生的会话状态。第三层inode。文件在磁盘上的元数据。包含文件大小、权限、数据块位置等。为什么需要中间这层因为多个fd可以指向同一个文件表项也可以各自指向不同的文件表项、但底层是同一个inode。这两种情况的语义完全不同。fd 1和fd 2通过dup2指向同一个文件表项共享文件偏移。fd 1写了10字节fd 2再写会从第10字节后面接着写。两次open同一个文件得到两个不同的fd表项各自指向不同的文件表项文件偏移相互独立。fd 1写到第100字节fd 2打开后从偏移0开始写会覆盖前面的内容。这个区别在日志场景中很重要。假如你两次open同一个日志文件分别给fd 1和fd 2往里面写东西因为它们偏移独立大概率会出现互相覆盖的现象。如果想要原子追加必须保证所有fd共享同一个文件表项或者每次都带O_WRONLY | O_APPEND让内核每次写之前把偏移移到末尾。5.2 dup、dup2、fork对fd表的影响dup和dup2上面讲过它们让两个fd共享同一个文件表项。fork的行为也值得单独说。fork时子进程会完整复制父进程的fd表也就是说子进程里的fd 0、1、2、3...和父进程完全一样且对应的文件表项也是共享的。fork之后父子进程同时往fd 1写数据时它们共享同一个文件偏移不会互相覆盖写的位置是连续推进的但会有交错问题——如果你不期望交错输出就需要加锁或使用独立的fd。这里有个很容易被忽视的问题fork之后父子进程共享同一个socket fd比如一个网络服务器的监听socket。子进程如果继承了监听fd但又不关会导致父进程关闭监听fd之后端口仍然被占用因为内核只会在所有引用该文件对象的fd都关闭后才会释放端口。所以规范做法是fork之后子进程立刻关闭不需要的fd父进程也及时关闭子进程专用的fd。在C或Go等多线程编程里还有一个经典陷阱某个线程中持有fdfork时fd被复制到了子进程但负责关闭它的线程在子进程里根本不存在了。解决办法是在exec之前扫描/proc/self/fd把所有没有设置O_CLOEXEC的fd全部关闭。5.3 为什么socket也是文件描述符Linux的设计哲学是一切皆文件。socket、管道、设备节点、普通文件在fd层面统一。你open一个TCP socket拿到的是一个fdsocket()系统调用返回的也是一个fd。这也意味着read/write可以从socket上读写数据close可以关闭socket连接select/poll/epoll可以监听socket fd的可读可写事件但要注意socket的语义和普通文件不一样。普通文件read一定会读到数据或EOF而socket上的read可能返回0表示对端关闭也可能返回-1并设置EAGAIN表示暂时没有数据非阻塞模式下。同理socket的write也不保证一次写完需要循环写。理解这一点对排查网络问题有直接帮助。如果你用strace跟踪一个网络程序会看到fd5这样的数字在各种系统调用中出现这个5就是一个socket fd。用lsof -p PID -i可以看这个fd对应的具体TCP连接状态。另外memfd_create这样的机制创建的内存文件也是fd它不落盘、只存在于内存本质上就是创建一个匿名文件并拿到fd。这种fd可以用于进程间共享内存也可以传给其他进程通过UNIX socket的SCM_RIGHTS实现零拷贝传递数据。这类技术在某些高性能场景很有用但建议先去理解fd基本模型再碰这些进阶玩法。6. 排查文件描述符问题的三板斧6.1 用 /proc/PID/fd 直接观察进程的fdLinux的/proc文件系统把每个进程的fd表暴露成了目录这是排查问题最直接的手段。# 查看某个进程的所有fd ls -l /proc/1234/fd/ # 只看数字总和 ls /proc/1234/fd/ | wc -l输出长这样lrwx------ 1 user user 64 Jan 1 10:00 0 - /dev/pts/2 lrwx------ 1 user user 64 Jan 1 10:00 1 - /var/log/app.log lrwx------ 1 user user 64 Jan 1 10:00 2 - /var/log/app.log lrwx------ 1 user user 64 Jan 1 10:00 3 - socket:[123456] lrwx------ 1 user user 64 Jan 1 10:00 4 - /var/lib/mysql/data.db每行都是一个符号链接箭头指向它的目标。从这里面能看出很多信息fd 1和fd 2都指向同一个文件说明程序或启动脚本做了合并重定向。fd 3指向socket说明程序持有网络连接。如果某些fd显示/path/to/file (deleted)说明文件已被删除但进程还持有这个fd这在日志滚动场景下特别常见。统计fd数量时注意ls | wc -l会包含一些隐藏问题吗实际上不会/proc/PID/fd下只有数字命名的目录项用ls -l | grep -c ^l更准确一点但直接用ls | wc -l也基本可靠。补充一个技巧当进程fd过多时ls可能会报错Argument list too long。这时用find来数find /proc/1234/fd -type l | wc -l6.2 用 lsof 定位泄漏源lsof是list open files的缩写它会把系统中所有进程的fd信息汇总起来功能比直接看/proc/PID/fd更强。常用的几个维度# 查看某个进程打开了哪些文件 lsof -p 1234 # 查看某个文件被哪些进程持有 lsof /var/log/app.log # 查看某个进程的网络连接 lsof -p 1234 -i -P # 查看所有已删除但还被占用的文件 lsof L1排查fd泄漏时我先用lsof -p PID | wc -l看总数再看lsof -p PID | grep deleted定位哪些fd指向已删除文件。如果发现某个fd数量一直在涨就要结合strace看代码路径了。对于Too many open files错误先确认进程的fd上限cat /proc/PID/limits里会有Max open files这一行默认继承自shell的ulimit。临时提高的话ulimit -n 65535但注意这只是改了当前shell和它启动的进程的上限。更规范的改法是写/etc/security/limits.conf不过这涉及系统级配置不同发行版略有差异。总之一句话治标先改上限治本要修代码里的fd泄漏。6.3 用 strace 跟踪系统调用找到泄漏的具体代码位置当你想知道程序到底在哪里打开了fd却没有关闭lsof只能看到结果strace能看到过程。# 跟踪进程的open/close/dup2调用 strace -f -e traceopen,openat,close,dup2 -p 1234 # 或者从启动开始跟踪并记录到文件 strace -f -e traceopen,openat,close,dup2 -o /tmp/trace.log ./appstrace输出里能看到每次open调用的参数和返回的fd号。如果你发现某一类文件反复被open但很少close那问题基本锁定了。举个例子有一段输出反复出现openat(AT_FDCWD, /etc/config.ini, O_RDONLY) 5 close(5) 0 openat(AT_FDCWD, /etc/config.ini, O_RDONLY) 5 close(5) 0这种打开又关闭是正常的因为每次open都拿最小的空闲fd。真正的泄漏场景是openat(AT_FDCWD, /var/log/data.log, O_WRONLY|O_CREAT, 0644) 6 openat(AT_FDCWD, /var/log/data.log, O_WRONLY|O_CREAT, 0644) 7 openat(AT_FDCWD, /var/log/data.log, O_WRONLY|O_CREAT, 0644) 8fd号不断递增也不关闭说明每次打开后没有close。把strace日志和代码行号对应起来就能快速修复。注意strace对性能有影响线上环境慎用尤其不要长时间跟踪高频IO的进程。实在需要的话可以加-p只附着一小段时间或者用-c统计系统调用次数不需要打印完整参数。6.4 顺手一个实用脚本统计fd被谁占用有时候系统里某个磁盘文件删不掉报device busy其实就是有进程还在用这个文件的fd。用fuser可以快速列出占用文件的进程fuser -v /path/to/file输出里能看到PID和进程名。如果确认可以释放fuser -k /path/to/file会发送SIGKILL给这些进程。不过用之前千万确认这个命令杀伤力很强写错路径会把系统服务干掉。另外还有个/proc/sys/fs/file-nr文件可以看整个系统当前的fd使用情况cat /proc/sys/fs/file-nr输出三个数字已分配fd数、未使用fd数通常是0、系统最大fd数。如果第一个数字接近第三个说明系统级别fd资源吃紧需要检查是否有进程在大量泄漏fd。这个文件是全局视角和单独的ulimit -n不是一个概念。7. 最后再分享几个贴近实战的小技巧7.1 用exec给当前shell添加fd普通重定向只对单条命令生效如果你想在shell脚本里一直保持某个重定向可以用execexec 3 /tmp/triple.txt echo hello 3 echo world 3 exec 3-exec 3file不是启动新进程而是在当前shell里打开fd 3之后所有写入fd 3的内容都进file。用完用exec 3-关闭。这在写脚本时处理日志特别方便。7.2 交换stdout和stderr有时候你希望程序的标准输出和标准错误互换可以用一个临时fd./app 31 12 23 3-一步步拆解31先把fd 3备份到当前stdout12把stdout指向stderr23把stderr指向原stdout最后3-关闭备份。这个操作不常用但能帮你验证程序是不是真的把错误写到stderr了——如果写反了交换后行为会暴露出来。7.3 后台任务输出到终端但不想被杀如果既想让进程输出打到终端又不想因为关闭终端导致进程死掉可以用disown./app disowndisown把任务从shell的任务表中移除这样shell退出时不会向它发送SIGHUP。但要注意如果进程直接往终端pty写终端关闭后它的fd 1/2仍然指向已失效的pts写入会出错。所以现实中只要进程需要长期运行就老老实实重定向到文件别指望终端fd能一直有效。我见过不少人图省事后台任务不重定向输出结果终端一关进程就没了日志也找不回来。这种问题在本地开发机上还好在远程服务器上就很痛苦——尤其跑了几天的训练任务突然中断连恢复现场的机会都没有。7.4 文件描述符和缓冲区的纠缠最后提醒一个容易混淆的点文件描述符是内核概念而printf/fwrite是libc的带缓冲IO。C程序在把数据交给内核之前会先写进用户态的stdio缓冲区。所以即使fd是正确的也不代表数据立刻落盘。如果你在程序里printf之后直接_exit(0)数据可能还在缓冲区就没了。解决方法是fflush(stdout)、fsync(fd)或者干脆用write(1, ...)直接写内核。shell重定向到文件时程序的stdout从终端变成文件libc的缓冲区策略也会变化——终端通常是行缓冲遇到换行就刷文件是块缓冲缓冲区满了才刷。所以你会看到同样的程序直接跑在终端上能实时打印日志重定向到文件后日志却延迟出现。这个现象经常被误判为程序卡住了其实是缓冲策略在作怪。排查这类问题可以用strace -e tracewrite看数据是否到了内核层如果write已经发生但文件里看不到那可能是内核页缓存和磁盘之间的问题一般不会或者你看了错误的文件。如果write都没发生那就是libc缓冲区没刷往程序里加fflush或者用stdbuf -oL启动就能解决。