从 Listen and fork 到 xinetd
我有一个 C 网络软件,目前在监听和分叉模式下工作。它正在监听某个服务器套接字并接受传入连接。然后它调用提供新接受套接字的核心服务器函数。
现在我正在尝试使该软件也可以在 xinetd 后面工作(取决于某些运行时参数)。我尝试直接调用提供文件描述符 0 而不是接受的套接字的核心服务器函数,但此方法不起作用。程序立即停止并出现 SIG_PIPE。
这种行为有什么明显的原因吗?我的核心函数执行一些低级套接字调用和信号处理。这应该在 xinetd 后面工作吗?
I have a piece of C network software that currently works in listen and fork mode. It's listening on some server socket and accepts incoming connection. Then it calls the core server function providing the new accepted socket.
Now I'm trying to make that software also work behind xinetd (depending on some runtime parameter). I tried to directly call the core server function providing file descriptor 0 instead of an accepted socket, but this method is just not working. The program immediately stops with a SIG_PIPE.
Is there any obvious reason for such behavior ? My core function performs some low level socket calls and signal handling. Is that supposed to work behind xinetd ?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
不能绝对确定,但并非您在套接字句柄上可以执行的所有操作也适用于普通文件句柄。首先,您无法写入标准输入。另外,某些系统调用可能需要套接字,例如
recv()
。编辑
另一种可能性:您的服务器进程是否在启动时关闭标准输入?
Not absolutely certain but not everything you can do on a socket handle also works with ordinary file handles. For a start, you can't write to stdin. Also some system calls probably need a socket e.g.
recv()
.Edit
Another possibility: does your server process close stdin as part of its start up?