我怎样才能释放一个“守护进程"?TCP 端口侦听器，在其拥有进程退出后? [英] How can I free a "daemon" TCP port listener, after its owning process exited?

问题描述

我有一个 .net 4.0 WCF 应用程序，它侦听 net.tcp 端口 667.(Windows 7 机器)
在某些时候，应用程序异常退出(例如，用户终止了进程).
现在发生了一件奇怪的事情:端口保持打开状态.当用户重新启动应用程序时，它无法侦听该端口，因为它已经在使用中.

I have a .net 4.0 WCF application that listens on net.tcp port 667. (Windows 7 machine)
At some point the application exits ungracefully (the user kills the process, for example).
Now a strange thing happens: The port remains open. When the user re-starts the application, it fails to listen on that port since it's already in use.

奇怪的是，即使拥有进程被杀死，操作系统也没有关闭端口，甚至在几个小时后也没有关闭.

The strange thing is that even though the owning process was killed, the OS does not close the port, not even after several hours.

以下是一些观察:

• 在 TcpView 上，进程是 ，PID 属于旧的(被杀死的)进程，状态是 LISTENING.本地地址是我的机器，并且该端口上有 IPV4 和 IPV6 侦听器.
• TcpView 上的关闭连接"和结束进程"操作对该端口没有影响.
• 进程资源管理器不显示旧的(终止的)进程.我试图搜索 PID 或端口，但一无所获.
• 运行netstat -a -b -n -o 时，所涉及的可执行文件显示为System，本地地址为0.0.0.0.其他信息与TcpView相同.

• On TcpView the process is <non-existent>, the PID belongs to the old (killed) process, and state is LISTENING. Local address is my machine and there are both IPV4 and IPV6 listeners on that port.
• "Close Connection" and "End Process" operations on TcpView have no effect on that port.
• Process Explorer does not display the old (killed) process. I tried to search-handle for the PID or the port but found nothing.
• When running netstat -a -b -n -o the executable involved is displayed as System and local address is 0.0.0.0. Other info is the same as TcpView.

我发现关闭该端口的唯一方法是重新启动系统...

The only way I found to close that port was a system reboot...

1. 有没有办法配置 WCF net.tcp 服务主机侦听器以避免在进程不正常存在后徘徊?
2. 有没有办法以编程方式关闭该端口?如果有，我的应用程序可以先关闭该端口，然后再尝试侦听它.
3. 是否有可以关闭此类守护进程"端口的实用程序?(因为 TcpView 不能这样做)
4. 这是操作系统错误吗?操作系统不应该跟踪此类守护进程"侦听器并在进程存在后关闭它们吗?

推荐答案

有没有办法配置WCF net.tcp服务主机监听器，避免进程不正常存在后拖延?

Is there a way to configure the WCF net.tcp Service Host listener to avoid lingering after the process exists ungracefully?

不，至少不是您应该使用的，但是有一种方法可以告诉它在重新启动时重用套接字地址，这样就没有必要了.

No, at least not that you should use, but there is a way to tell it to reuse the socket address when it restarts, which makes that unnecessary.

有没有办法以编程方式关闭该端口?如果有，我的应用程序可以先关闭该端口，然后再尝试侦听它.

Is there a way to programatically close that port? If there is, my application could first close that port before trying to listen to it.

没有.只有打开端口的应用程序才能关闭它.

No. Only the application that opened a port can close it.

是否有可以关闭此类守护进程"端口的实用程序?(因为 TcpView 不能这样做)

Is there a utility that could close such "daemon" ports? (since TcpView cannot do that)

不，见上文.

这是操作系统错误吗?操作系统不应该跟踪此类守护程序"侦听器并在进程存在后关闭它们吗?

Is this an OS bug? Shouldn't the OS keep track of such "daemon" listeners and close them once the process exists?

进程退出时，包括TCP端口在内的所有进程资源都应该被释放.TCP 'ESTABLISHED' 端口有一个例外，出于 TCP 安全原因，它会挂起几分钟.

All the process's resources including TCP ports should be relased when the process exits. There is an exception in the case of TCP 'ESTABLISHED' ports, which hang around for a couple of minutes for TCP security reasons.

听起来好像有一个子进程继承了仍然处于活动状态的套接字.

It sounds like there is a sub-process that inherited the socket that is still active.

这篇关于我怎样才能释放一个“守护进程"?TCP 端口侦听器，在其拥有进程退出后?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！