mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 08:05:49 -06:00
[GH-ISSUE #369] 写了个脚本让frpc定时重连,但重连的时候报already in use #272
Labels
No labels
In Progress
WIP
WaitingForInfo
bug
doc
duplicate
easy
enhancement
future
help wanted
invalid
lifecycle/stale
need-issue-template
need-usage-help
no plan
proposal
pull-request
question
todo
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/frp#272
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @laoyur on GitHub (Jun 17, 2017).
Original GitHub issue: https://github.com/fatedier/frp/issues/369
Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间,提高处理问题的效率,不按照格式填写的 issue 将会直接关闭。)
Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST
What version of frp are you using (./frpc -v or ./frps -v)?
0.11.0
What operating system and processor architecture are you using (
go env)?frps: ubuntu 14.04 x64
frpc: windows 7 x86
Steps to reproduce the issue:
Describe the results you received:
大部分时间工作正常,有时候重连的时候就报错,端口already in use
Additional information you deem important (e.g. issue happens only occasionally):
frps admin里面,显示该proxy一直online,即便我已经把frpc停了。
然后frps所在server,发现大量的CLOSE_WAIT:
疑问1:我该如何安全地实现『不修改frpc.ini(即需要固定使用同一个端口)的情况下,定时让frpc稳定地重连』?目前我采用的是强杀frpc,但上面的效果显示这种方案显然有问题
疑问2:一旦出现上述情况:frps admin显示frpc一直在线、大量连接CLOSE_WAIT、frpc其实早就已经不在运行、新frpc进程连过来又报already in use,除了关闭frps外,有没有其他解决方案?
@fatedier commented on GitHub (Jun 17, 2017):
根据你的重现步骤,无法复现问题。
dashboard 需要刷新,客户端是否下线通过日志最容易看。
不明白重新启动 frpc 的意义是什么。
@laoyur commented on GitHub (Jun 17, 2017):
frps日志没开……
但是dashboard确实是在frpc杀掉后,刷新过,重复好几遍,也等了好久,依然显示frpc在线,这点我不会乱说
看现象还是挺明了的:大量连接CLOSE_WAIT,然后frps错误地认为frpc还在线,新的frpc实例连过来,但一直被拒绝,因为该端口already in use。其实这种情况下,frps还是可以鉴别出来,之前那个frpc已经事实上掉线了,至少心跳肯定已经没有了,不知道这里我有没有理解错。
当然我重新启动frpc的做法是不太妥当,我本来以为强杀后重连,是不是比frpc自己掉线重连机制能更快恢复通讯
@fatedier commented on GitHub (Jun 17, 2017):
看超时,默认 90s,但你提供的信息不足,也没法复现排查这个问题。
有一个新的客户端连接过来,是否立即释放上一个客户端的资源是需要慎重考虑的。目前是保守的方式,只有上一个客户端退出后,才允许同名的连接。
有一种例外,每一次客户端连接服务端后会获取到一个 RunId,从客户端连接到退出是不会改变的。如果断网,重连时,会附带上这个 RunId,服务端如果检测到相同,会知道是同一个客户端,就会立即释放之前占用的资源,完成重连。当你手动停止进程,重启后,会拿到一个新的 RunId,所以被认为是另一个客户端。
@laoyur commented on GitHub (Jun 18, 2017):
感谢解答!
关于超时,我用的是默认配置。
上述情况确实不是必现,以上重启frpc的方案我稳定跑了好多天后,昨天才遇到 :(
说起为何要重启frpc,原因1是之前发过的一个问题,加密和压缩,当时只说frps占用内存异常,其实frpc也占内存较大的,3分钟即能跑到一二百兆,我frpc是给用户终端提供的代理服务,每5分钟换一次ip,所以我索性在换ip后就杀掉frpc并重连了(我现在关闭加密和压缩了,frpc的内存占用已经没那么大,但定期重启frpc还是对内存占用方面,应该还是有些微帮助的吧);原因2是单方面地期望于杀掉重连能更快速地恢复跟frps的重连。
这段我同意,不过『上一个客户端退出』这点是如何鉴定的呢,超时应该也算作其一吧?是不是说我遇到的问题,是某种情况下导致超时机制检测失败了,这才是问题的根源?我可以确认的是,等我发现这个问题时,距离出事情的那个frpc客户端掉线(实际上是所在vps换IP后被我强杀),已经过去了几十分钟甚至更长时间,在这段时间内不停地(每5分钟)有新的同名frpc实例连到frps上,但都因为上述策略而被拒。
所以,有没有可能增加一种配置策略,可以达到『有一个新的客户端连接过来,可以立即释放上一个客户端(RunId)的资源』这种目的。
如果觉得这种需求毕竟小众,不会被采纳的话,暂时我只能更改我的策略,取消重启frpc这种方案
@fatedier commented on GitHub (Jun 18, 2017):
重启对于内存占用没有太大帮助,很快又会恢复到正常占用的数值。
网络情况很复杂,你的问题需要明确的可复现的环境和步骤才能解决。最好是你自己在同样的环境下另外搭建服务端和客户端测试,记录使用的配置,日志,网络环境信息等内容。