macos linux 上的文件描述符 3 有什么特别之处？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3535282/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What's so special about file descriptor 3 on linux?
提问by colding
I'm working on a server application that's going to work on Linux and Mac OS X. It goes like this:
我正在开发一个可以在 Linux 和 Mac OS X 上运行的服务器应用程序。它是这样的：
- start main application
- fork of the controller process
- call lock_down() in the controller process
- terminate main application
- the controller process then forks again, creating a worker process
- eventually the controller keeps forking more worker processes
- 启动主应用程序
- 控制器进程的分支
- 在控制器进程中调用lock_down()
- 终止主应用程序
- 然后控制器进程再次分叉，创建一个工作进程
- 最终，控制器不断分叉更多的工作进程
I can log using several of methods (e.g. syslog or a file) but right now I'm pondering about syslog. The "funny" thing is that no syslog output is ever seen in the controller process unless I include the #ifdef section below.
我可以使用多种方法（例如 syslog 或文件）进行日志记录，但现在我正在考虑 syslog。“有趣”的是，除非我包含下面的 #ifdef 部分，否则在控制器进程中从未看到任何系统日志输出。
The worker processes logs flawlessly in Mac OS X and linux with or without the ifdef'ed section below. The controller also logs flawlessly in Mac OS X without the #ifdef'ed section, but on linux the ifdef is needed if I want to see any output into syslog (or the log file for that matter) from the controller process.
工作进程在 Mac OS X 和 linux 中完美地记录日志，无论是否带有下面的 ifdef'ed 部分。控制器在没有 #ifdef'ed 部分的 Mac OS X 中也可以完美地记录，但是在 linux 上，如果我想从控制器进程中看到任何输出到 syslog（或与此相关的日志文件）中，则需要 ifdef。
So, why is that?
那么，这是为什么呢？
static int
lock_down(void)
{
struct rlimit rl;
unsigned int n;
int fd0;
int fd1;
int fd2;
// Reset file mode mask
umask(0);
// change the working directory
if ((chdir("/")) < 0)
return EXIT_FAILURE;
// close any and all open file descriptors
if (getrlimit(RLIMIT_NOFILE, &rl))
return EXIT_FAILURE;
if (RLIM_INFINITY == rl.rlim_max)
rl.rlim_max = 1024;
for (n = 0; n < rl.rlim_max; n++) {
#ifdef __linux__
if (3 == n) // deep magic...
continue;
#endif
if (close(n) && (EBADF != errno))
return EXIT_FAILURE;
}
// attach file descriptors 0, 1 and 2 to /dev/null
fd0 = open("/dev/null", O_RDWR);
fd1 = dup2(fd0, 1);
fd2 = dup2(fd0, 2);
if (0 != fd0)
return EXIT_FAILURE;
return EXIT_SUCCESS;
}
camh was close, but using closelog() was the idea that did the trick so the honor goes to jilles. Something else, aside from closing a file descriptor from under syslogs feet must go on though. To make the code work I added a call to closelog() just before the loop:
camh 很接近，但是使用 closelog() 是成功的主意，因此荣誉归 jilles。除了关闭系统日志脚下的文件描述符之外，还必须继续进行其他操作。为了使代码工作，我在循环之前添加了对 closelog() 的调用：
closelog();
for (n = 0; n < rl.rlim_max; n++) {
if (close(n) && (EBADF != errno))
return EXIT_FAILURE;
}
I was relying on a verbatim understanding of the manual page, saying:
我依靠对手册页的逐字理解，说：
The use of openlog() is optional; it will automatically be called by syslog() if necessary...
openlog() 的使用是可选的；如有必要，它将由 syslog() 自动调用...
I interpreted this as saying that syslog would detect if the file descriptor was closed under it. Apparently it did not. An explicit closelog() on linux was needed to tell syslog that the descriptor was closed.
我将此解释为 syslog 会检测文件描述符是否在其下关闭。显然没有。linux 上需要一个显式的 closelog() 来告诉 syslog 描述符已关闭。
One more thing that still perplexes me is that not using closelog() prevented the first forked process (the controller) from even opening and using a log file. The following forked processes could use syslog or a log file with no problems. Maybe there are some caching effect in the filesystem that make the first forked process having an unreliable "idea" of which file descriptors are available, while the next set of forked process are sufficiently delayed to not be affected by this?
还有一件令我困惑的事情是，不使用 closelog() 会阻止第一个分叉进程（控制器）甚至无法打开和使用日志文件。以下分叉进程可以使用 syslog 或日志文件，没有问题。也许文件系统中存在一些缓存效应，使第一个分叉进程对哪些文件描述符可用具有不可靠的“想法”，而下一组分叉进程被充分延迟而不受此影响？
采纳答案by jilles
syslog(3) may keep a file descriptor to syslogd's socket open; closing this under its feet is likely to cause problems. A closelog(3) call may help.
syslog(3) 可以保持一个文件描述符到 syslogd 的套接字打开；在它的脚下关闭它可能会导致问题。closelog(3) 调用可能会有所帮助。
回答by camh
The special aspect of file descriptor 3 is that it will usually be the first file descriptor returned from a system call that allocates a new file descriptor, given that 0, 1 and 2 are usually set up for stdin, stdout and stderr.
文件描述符 3 的特殊之处在于它通常是从分配新文件描述符的系统调用返回的第一个文件描述符，因为通常为 stdin、stdout 和 stderr 设置 0、1 和 2。
This means that if any library function you have called allocates a file descriptor for its own internal purposes in order to perform its functions, it will get fd 3.
这意味着如果您调用的任何库函数为其内部目的分配了一个文件描述符以执行其功能，它将获得 fd 3。
The openlog(3) library call will need to open /dev/logto communicate with the syslog daemon. If you subsequently close all file descriptors, you may break the syslog library functions if they are not written in a way to handle that.
openlog(3) 库调用需要打开/dev/log才能与 syslog 守护进程通信。如果您随后关闭所有文件描述符，并且系统日志库函数的编写方式无法处理这些函数，则可能会破坏它们。
回答by Matthew Slattery
The way to debug this on Linux is to use straceto trace the actual system calls that are being made; the use of a file descriptor for syslog then becomes obvious:
在 Linux 上调试它的方法是strace跟踪正在执行的实际系统调用；系统日志的文件描述符的使用变得明显：
$ cat syslog_test.c
#include <stdio.h>
#include <syslog.h>
int main(void)
{
openlog("test", LOG_PID, LOG_LOCAL0);
syslog(LOG_ERR, "waaaaaah");
closelog();
return 0;
}
$ gcc -W -Wall -o syslog_test syslog_test.c
$ strace ./syslog_test
...
socket(PF_FILE, SOCK_DGRAM, 0) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 16) = 0
send(3, "<131>Aug 21 00:47:52 test[24264]"..., 42, MSG_NOSIGNAL) = 42
close(3) = 0
exit_group(0) = ?
Process 24264 detached
回答by jdehaan
Syslog binds on a given descriptor at startup. Most of the time descriptor 3. If you close it no logs.
Syslog 在启动时绑定给定的描述符。大多数时间描述符 3。如果关闭它没有日志。
syslog-ng -d -v
Gives you more info about what it's doing behind the scenes.
为您提供有关其幕后工作的更多信息。
The output should look like something like this:
输出应如下所示：
binding fd 3, inetaddr: 0.0.0.0, port: 514
io.c: Preparing fd 3 for reading
io.c: Preparing fd 4 for reading
binding fd 5, unixaddr: /dev/log
io.c: listening on fd 5
