![设置](https://linux22.com/image/766403/%E8%AE%BE%E7%BD%AE.png)
设置
我有这样的设置:
Windows 10 pro
带有WSL2
内部Ubuntu 20.04
。- 在 Ubuntu 中,我有一个运行
docker engine
良好的程序,它已经运行了几个月,公开了多个端口范围,包含数十个图像和容器。一切都很完美。
NFS 版本 3 和端口 111
今天在玩一个 NFS 服务器,必须运行在版本 3 上。111
除了 port 之外,还需要Port 2049
。最初的测试是用 image 进行的erichough/nfs-server
。
我把问题缩小到了这个最小失败示例:
如果我这样做:
docker run -it --rm -p 111:111 alpine
我明白了:
docker: Error response from daemon: driver failed programming external connectivity on endpoint hardcore_kilby (9aa7466f1771c9b5926a00eede289fc1084a12ee09ea2f3deee917c4734034c9): Error starting userland proxy: listen tcp4 0.0.0.0:111: bind: address already in use.
这表明该端口111
被主机使用。
丢弃它与知名港口范围我绑定了一个不同的端口:112
而不是111
,并且成功了:
因此我认为有一个进程正在监听端口111
。
111 端口没人吗?
这StackOverflow 上的回答说资源监控可以完成查找“哪个进程阻塞了端口”的任务。我启动了它,按“端口”对“正在监听的端口”列表进行了排序,然后……
哦,惊喜!!!端口上没有人监听111
!
RPC 是否阻塞端口?
这以下是@Drixter 的回答建议netstat -tapneu
查看该端口是否111
被RPC阻塞。
在 Linux 方面
netstat -tapneu
仅适用于 WSL 的 Linux 端并报告不111
正在使用的端口。
在 Windows 方面
在 WSL 的 Windows 端(例如通过 git-bash),该-u
选项不存在,该-e
选项将结果折叠为统计数据,并且-p
需要一个额外的参数。所以我将范围缩小到netstat -tan
和netstat -n
。
和没有任何这些报告端口111
。
深入了解
我的电脑在局域网中有一个固定的 IP 地址192.168.3.xx
。如果我为选项指定 IP -p
,我可以看到端口111
只用于环回:(127.0.0.1
也用于其他lo
地址,如127.0.0.2
、127.0.0.3
等),但端口是自由的在 LAN 地址上:
为什么?
- 为什么会发生这种情况?
- 在我的情况下,IP 是静态的。我是否应该只将
111
Docker 容器暴露给 LAN 地址上的主机,并且永远不能在该地址中完成localhost
? - 难道是端口
111
被使用了但是“检测不到”? - 我能否查看我是否确实有这个 RPC 东西以及它在 Windows 端的状态?
答案1
您确定 RPC 没有使用端口 111 吗?
netstat -tapneu | grep 111
答案2
我很好奇。
那么,它说“端口正在使用”,以下 powershell 命令的输出是什么?
Get-Process -Id (Get-NetTCPConnection -LocalPort 111).OwningProcess | Format-List *
这应该会生成一个在 Windows 中监听该端口的进程列表。我只是好奇它是否会提供与资源监视器相同的信息。
如果上述 powershell 没有输出,则
sudo ss -tulpn | grep 111
在 WSL 中运行应该提供 Linux 子系统中监听该端口的任何内容的 pid。
这些至少应该可以明确地告诉您它是否是原始端口碰撞,或者是否实际上没有任何东西在监听该端口并且发生了一些更奇怪的事情。