mirror of
https://github.com/fatedier/frp.git
synced 2026-05-15 16:15:49 -06:00
[PR #2467] [MERGED] Fix server-side proxy inappropriate quit when met accept: too many open files error #4581
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#4581
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?
📋 Pull Request Information
Original PR: https://github.com/fatedier/frp/pull/2467
Author: @leiless
Created: 7/2/2021
Status: ✅ Merged
Merged: 7/5/2021
Merged by: @fatedier
Base:
dev← Head:dev📝 Commits (6)
afffbb5proxy.go: Don't close listener when met 'accept: too many open files' error0ab00c8frpc@.service: Rectify systemd run type from idle to simple2cfba84systemd: Setulimit -nto 1048576 by defaultc5be960conf/systemd/: Remove unnecessary commentsa41824bproxy.go: Adopt proper error handling from net/mux/mux.go#Serve()f01f36eproxy.go: Minor cleanup due to PR feedbacks📊 Changes
5 files changed (+23 additions, -2 deletions)
View changed files
📝
conf/systemd/frpc.service(+1 -0)📝
conf/systemd/frpc@.service(+2 -1)📝
conf/systemd/frps.service(+1 -0)📝
conf/systemd/frps@.service(+1 -0)📝
server/proxy/proxy.go(+18 -1)📄 Description
How this happen
When the
frpshave massive concurrent connection establishments(especially for long-lived connections, e.g. http2, WebSocket),frpswill use many file descriptors(expected behaviours), and eventually reach theulimit -nlimit.After that the
frpsproxy listener simply log and quit, and the wholefrpsis refused to accepting any further connections.Which is prone to DDOS attacks.
How to reproduce this bug
frpsNo config file required, just use the defaults.
frpcclient.iniWhy use DNS for test: simply because it's relative long-lived, anything else would be ok.
concurrent-conn.shReproduce procedures
Env: Ubuntu 20.04.2 LTS x86_64
./frps./frpc -c client.iniprlimit --pid $(pidof frps) --nofile=128:128Explicitly decrease nofile limit of
frpsto reachulimit -nquicklyprlimit --pid $(pidof frpc) --nofile=102400:102400Explicitly increase nofile limit of
frpcsofrpcwon't be the bottleneck./concurrent-conn.shfrpsoutputVerification taken from
concurrent-conn.sh🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.