Linux 守护进程和 STDIN/STDOUT

我正在开发一个 Linux 守护进程，并且在标准输入/标准输出方面遇到一些问题。通常，由于守护进程的性质，您没有任何标准输入或标准输出。但是，我的守护程序中确实有一个函数，当守护程序第一次运行时会调用该函数，以指定守护程序成功运行所需的不同参数。当这个函数被调用时，终端变得非常缓慢，我必须启动一个单独的 shell 并使用 top 杀死守护进程以获得响应提示。现在我怀疑这与关闭标准输入/标准输出的分叉过程有关，但我不太确定如何解决这个问题。如果你们能对这种情况有所了解，我们将不胜感激。谢谢。

Edit:

int main(argc, char *argv[]) {

/* setup signal handling */

/* check command line arguments */

pid_t pid, sid;

pid = fork();

if (pid < 0) {
exit(EXIT_FAILURE);
}

if(pid > 0){
exit(EXIT_SUCCESS);
}

sid = setsid();

if(sid < 0) {
exit(EXIT_FAILURE);
}

umask(027);

/* set syslogging */

/* do some logic to determine wether we are running the daemon for the first time and if we are call the one time function which uses fgets() to recieve some input */

while(1) {

/* do required work */

}

/* do some clean up procedures and exit */

return 0;
}

你们提到使用配置文件。这正是我存储通过输入接收到的参数所做的事情。不过，我最初仍然需要通过标准输入从用户那里获取这些信息。确定我们是否是第一次运行的逻辑是基于配置文件是否存在。

通常，守护程序的标准输入应连接到/dev/null，这样如果从标准输入读取任何内容，您会立即得到 EOF。通常，标准输出应该连接到一个文件 - 日志文件或/dev/null。后者意味着所有写入都会成功，但不会存储任何信息。同样，标准错误应该连接到/dev/null或到日志文件。

所有程序（包括守护程序）都有权假定 stdin、stdout 和 stderr 是适当打开的文件流。

守护进程通常可以控制其输入的来源和输出的去向。很少有机会来自其他方面的输入/dev/null。如果编写代码是为了在没有标准输出或标准错误的情况下生存（例如，它打开标准日志通道，或者可能使用syslog(3)）那么关闭 stdout 和 stderr 可能是合适的。否则，将它们重定向到可能是合适的/dev/null，同时仍将消息记录到日志文件中。或者，您可以将 stdout 和 stderr 重定向到日志文件 - 请注意不断增长的日志文件。

您的响应时间缓慢到不可能，可能是因为您的程序没有注意某处读取循环中的 EOF。它可能会提示用户在 /dev/null 上输入，并从 /dev/null 读取响应，但没有得到“y”或“n”返回，它会再次尝试，这会严重影响您的系统。当然，该代码的缺陷在于不处理 EOF，并计算获得无效响应的次数，并在合理的尝试次数（16、32、64）后停止愚蠢。如果程序期望得到有意义的输入但仍然得不到它，它应该理智且安全地关闭商店。