-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
运行一夜后核心无法接受任何连接,错误:too many open files #4194
Comments
按理来说五分钟不活动会自动清掉 |
自动清除是内核做的还是xray-core做的 |
|
@xqzr 感谢,我看了,用的都是默认值,300s的超时感觉只对TCP生效了 |
看了下代码好像是有这个 bug,晚点我修下 |
是不是等這個修好才會發新版? |
想等 XUDP 文章发出后再发新版,之前说圣诞发文,结果是我太天真了,最近天天在外面玩 |
"defer pw.Close()" 用于清理 fake UDP,之前是写在主函数 Process() 里的,但由于末尾 task.Run() 的特性,可能 Process() 都 return 了但 responseDone() 还在执行,导致提前清理了 fake UDP、后面的没清理 2782f13 把 "defer pw.Close()" 移到 responseDone() 里了,试试 https://github.com/XTLS/Xray-core/actions/runs/12504877161
|
辛苦了,我测验一下,尽快给出结果 |
@RPRX 测试了一下,问题应该没有被修复,目前udp连接已经上升到1w+,即使我把LAN区域设备断网(就等于拔网线),等待十几分钟后,udp连接也没有减少。 |
@Fangliding 问题任然存在,根[RPRX]的提交一样,期间UDP有少量减少,但是整体还是飞速上升,5分钟2000个连接,断网十分钟后,UDP连接任然不减少(还增长几十个)。 |
切换clash 20分钟后,网关的网络连接情况:
UDP连接不多,一直在十几到二十几徘徊。 在passwall2里面关闭UDP代理,使用是一点问题没有,很完美。 |
打log看了一眼 不管是原来是超时逻辑还是后面加的 都会正常返回 如果真像怀疑的那样就是 leak goroutine 早炸的满天星了 |
@Fangliding 依旧,也将配置手动给成:
哈哈,先睡吧,来日方长 |
@Fangliding 刚刚评论完,程序发生了异常
后增: 试了两次,发现都是启动后5-6分钟的时间节点奔溃,好像是什么资源在5分钟后自动回收的代码内存异常,idle时间确实改成了10秒。 |
https://github.com/XTLS/Xray-core/actions/runs/12507019416 这个呢 还是不行不猜谜了 得以后有时间再弄个透代自己看了 |
@Fangliding 测试大概7 8分钟,问题依旧
|
几百个的时候在那晾着会掉下去吗 |
不会掉,不过我在防火墙那边发现,导致UDP快速增加的原因是BT流量(应该是员工下载东西),但是即使把BT流量禁用掉,UDP也是不停增加,只是速度慢点,大概2秒一个这样子。 后增: BT禁用一段时间后,UDP也没有释放,且依然在增加。 |
我自己测了一下 数千并发核心都可以正常回收两个socket不会有任何泄露问题 复现不了 |
@Fangliding 所以 main 的代码没问题吗 |
我是在main分支最新的代码上测的 之前我怀疑close有问题没法正确回收但是测了可以 至于先前的修复 我打了俩defer输出日志 两个地方的defer(旧的和新加的)都是可以正确执行 应该不是那的问题 不过我也没测 |
@Fangliding main 分支那个修复应该还是有些用的,因为 Process() return 时可能下行还在 copy,导致提前清理了、后面的没清理 |
其实这个以后可以改成烧火棍,就是直接构造 IP 包:#237 (comment) |
配置文件有吗,是通过openwrt吗,我研究一下 |
@Fangliding @RPRX 好消息!! 当我在把网络中所有BT流量禁用后,并且重新启动xray(idle是10秒),运行10分钟后UDP连接增张到150+,观察十几分钟发现一直在50-200之间振荡。然后我把所有员工上网流量路由到其他网关去(等于断网),此时这个网关没有任何网络活动,一段时候后UDP降到3个。来回测试了很多遍,发现只要断网30s,UDP立刻降到3个,其实这三个都是xray自己的服务端口,也就是说此时不再有任何UDP连接泄露! |
@Fangliding @RPRX 晚上再次进行了详细测试,终于被我发现问题的根本原因,就是UDP释放不及时。 正常网络环境中很难察觉异常,但其实如果仔细一点就会发现,绝大部分UDP连接是在断网一段时间后,同时释放,这个其实不应该,因为UDP通常是逐步建立的,所以断网后应该逐步释放。 为了进一步确定问题,我特地配置了一个BT环境,使用的软件是qBittorrent,找了一些资源下载试试,果然UDP连接大量且快速的建立,在xray的日志中可以看到这一点, 我截取日志一段。
就这样一直持续十几分钟,很快UDP连接达到4000+,并且开始报错too many open files。 就好像新建立UDP给老的UDP续上命了。猜想:defer没有在正确的时间执行,可能是资源被意外引用了,延续了连接的生命周期。 一言以蔽之,只要你能复现出UDP大部分连接是同时释放,那就说明这个bug是存在的。 希望我的测试能够提供给开发者有意义的帮助。 |
@jpsn123 我觉得你的测试的确是有帮助的,回想我说的
这个如果极限一点,上行都五分钟超时了,下行还在一直接收数据,就会导致那些 UDP 迟迟没有释放,断网才能释放 但问题是 UDP 又不像 TCP 能知道客户端收没收,可能客户端早就不要了,下行还在一直发给客户端 所以对于 UDP,应当改成仅以上行超时为标准,上行超时了就把下行也打断 |
a8559a1 改成了 UDP 上行超时后打断下行并清理 fake UDP,先看看效果,其实 Socks5 由于 *ray 实现不标准,也应该这么改 关于 task、pipe 等逻辑有点杂乱,以后再理,总之先加了些 @jpsn123 试试 https://github.com/XTLS/Xray-core/actions/runs/12523589260 |
|
这是预期行为,因为 Xray 会按下行 UDP 包的源地址缓存 fake UDP,就不用反复创建,其它软件比如 Clash 是只用一次就销毁 上行五分钟不活跃后,所有与这次代理相关的 fake UDP 会被一起释放,v25 改成直接构造 IP 包吧 你可以先提升系统 limit,但话说回来,其他人没遇到这个问题可能是他们早就把 BT 禁了,因为可能会封 VPS |
好,感谢 @RPRX |
完整性要求
描述
背景介绍:
我是使用openwrt安装passwall2插件来间接使用xray-core,passwall2是配置的透明代理,提供给50人团队日常使用,以前使用一直很正常,就是代理相比clash有点慢。最近更新了openwrt,passwall2也是用最新版,xray-core核心也升级到了24.11.30版本。新的环境配置好后一切正常,而且比升级前快不少,除了有时解析国内网站DNS慢(应该是把国内站点的域名路由到国外了解析了)。
问题出现
刚刚启动xray是没有任何问题的,但是过一夜后,xray无法接受任何路由到1041端口的流量,日志提示
[Warning] transport/internet/tcp: failed to accepted raw connections > accept tcp [::]:1041: accept4: too many open files
。此时xray核心无法正常关闭,重启命令
/etc/init.d/passwall2 restart
会一直被阻塞住。使用命令
netstat -an
会打印出超多udp连接,我截取一段:这些udp连接没有被正确释放,所以go的socket无法接受新的连接,网上有提升limit的方式,但我感觉这个问题不是达到上限,而是连接泄露。
我开始我以为是openwrt问题,我尝试过切换到以前的openwrt稳定版本,5.15内核,使用最新的xray,问题仍然存在。passwall2只是一个配置生成器,生成的配置文件我检查了也没有问题,应该不会是passwall2的问题,所以我想很可能是xray问题。
恢复方法
只能强制kill掉xray-core进程,之后一切正常,一夜之后又是同样的错误。
重现方式
bug比较难以重现,内网机器要多(其实就是上网用户很多),然后等待一段时间,必然出现
客户端配置
配置文件已去密,由passwall2最新版生成,配置文件没有什么问题,因为一开始是可以正常工作的
服务端配置
无关服务端
客户端日志
截取部分日志
服务端日志
无关服务端
The text was updated successfully, but these errors were encountered: