关闭telnet会话会将标准输出重定向到http套接字

Question

我有一个程序，将日志输出显示到标准输出。

因此，如果我打开到目标linux的telnet会话，然后在该telnet会话中启动我的程序，那么我将获得显示在telnet会话中的日志消息。

在我的程序中，我正在运行一个小的http服务器。 现在，如果我更改目标linux的IP地址，然后重新启动接口（http服务器将自动重新启动，因为我通过netlink检测到ip地址的更改），然后将关闭telnet会话，并将stdout消息重定向到我的http服务器打开的套接字上，我将锁定日志消息的printf。

我尝试使用select来检测到此锁定，但未成功： 如何在stdout中使用select？

选择成功后，将转到主对象（已锁定）

有什么建议可以避免这个问题？

Answer 1

如果我理解正确，则由于IP地址的更改，正在运行HTTP服务器的telnet会话（为什么不使用SSH ？？）会中断。

之后，如果程序继续向该会话写入数据（即其stdout），则将首先在系统缓冲数据时写入成功，然后最终写入将阻塞（而不是“锁定”）。 最后，TCP连接将超时并且写入将返回错误。 TCP会话超时可能会花费很长时间，也可能不会很长，但最终会。

如果要避免阻塞，可以使日志输出代码对stdout使用非阻塞写入（例如，如果您的应用程序是事件驱动的并且不能阻塞）。 您将需要使用fcntl将stdout更改为非阻塞，并且您可能需要完全避免使用stdio，因为stdio并非旨在与非阻塞输出一起使用。 您必须实现自己的缓冲并直接写入文件描述符1。

您还提到了在标准输出日志损坏后要登录到HTTP连接。 您也可以这样做（一旦在写入stdout时出错，就会触发该操作），但这将需要更多工作。 您将必须在应用程序内部管理日志缓冲区，直到HTTP客户端连接并请求它为止。 如果没有太大的日志（如果没有HTTP客户端连接），您还希望添加一条丢弃日志的规定。 所有这些都超出了SO问题的范围...