github-starred/frp
2
0
Fork 0
mirror of https://github.com/fatedier/frp.git synced 2026-05-15 08:05:49 -06:00
Code Issues 40 Projects Packages Wiki Activity Actions 1

[GH-ISSUE #1842] Sleep can break ability to reconnect #1454

New issue
Closed
opened 2026-05-05 12:55:19 -06:00 by gitea-mirror · 4 comments
gitea-mirror commented 2026-05-05 12:55:19 -06:00
Owner
Copy link

Originally created by @keyoti on GitHub (Jun 5, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/1842

I am seeing a lot of this in my logs

2020/06/05 04:40:26 [I] [service.go:514] [ce09965c55e3308d] client login info: ip [172.x.x.x:58672] version [0.33.0] hostname [] os [windows] arch [amd64]
2020/06/05 04:40:26 [I] [control.go:289] [ce09965c55e3308d] Replaced by client [ce09965c55e3308d]
2020/06/05 04:40:56 [I] [service.go:514] [ce09965c55e3308d] client login info: ip [172.x.x.x:59868] version [0.33.0] hostname [] os [windows] arch [amd64]
2020/06/05 04:40:56 [I] [control.go:289] [ce09965c55e3308d] Replaced by client [ce09965c55e3308d]
Repeat every 30 seconds for ever

What version of frp are you using (./frpc -v or ./frps -v)?

0.33.0

What operating system and processor architecture are you using (go env)?

Server is Ubuntu x64, client is Windows 10

Configures you used:

Running FRPS as a TCP backend node behind HAProxy
HTTPS proxy service only

Steps to reproduce the issue:

  1. Run frps
  2. Connect from frpc
  3. Sleep computer for a long time (seems to need hours??)

Describe the results you received:

frpc cannot reconnect properly, it keeps trying to reconnect and stalls. User must kill frpc manually and restart it.

Describe the results you expected:

frpc should be able to reconnect like normal

Additional information you deem important (e.g. issue happens only occasionally):

I am new at Go, but I suspect the problem is because of this:

In server Service.RegisterControl, you do

ctl := NewControl(ctx, svr.rc, svr.pxyManager, svr.pluginManager, svr.authVerifier, ctlConn, loginMsg, svr.cfg)
	if oldCtl := svr.ctlManager.Add(loginMsg.RunId, ctl); oldCtl != nil {
		oldCtl.allShutdown.WaitDone()
	}

	ctl.Start()

In my situation I don't think ctl.Start() is ever called because oldCtl.allShutdown.WaitDone() is hanging.

oldCtl.allShutdown.WaitDone() is:

func (s *Shutdown) WaitDone() {
	<-s.doneCh
}

Is it true that a channel can block indefinitely if the TCP connection is dead? Is it possible to time it out?

Thanks!

Originally created by @keyoti on GitHub (Jun 5, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/1842 I am seeing a lot of this in my logs ``` 2020/06/05 04:40:26 [I] [service.go:514] [ce09965c55e3308d] client login info: ip [172.x.x.x:58672] version [0.33.0] hostname [] os [windows] arch [amd64] 2020/06/05 04:40:26 [I] [control.go:289] [ce09965c55e3308d] Replaced by client [ce09965c55e3308d] 2020/06/05 04:40:56 [I] [service.go:514] [ce09965c55e3308d] client login info: ip [172.x.x.x:59868] version [0.33.0] hostname [] os [windows] arch [amd64] 2020/06/05 04:40:56 [I] [control.go:289] [ce09965c55e3308d] Replaced by client [ce09965c55e3308d] Repeat every 30 seconds for ever ``` **What version of frp are you using (./frpc -v or ./frps -v)?** 0.33.0 **What operating system and processor architecture are you using (`go env`)?** Server is Ubuntu x64, client is Windows 10 **Configures you used:** Running FRPS as a TCP backend node behind HAProxy HTTPS proxy service only **Steps to reproduce the issue:** 1. Run frps 2. Connect from frpc 3. Sleep computer for a long time (seems to need hours??) **Describe the results you received:** frpc cannot reconnect properly, it keeps trying to reconnect and stalls. User must kill frpc manually and restart it. **Describe the results you expected:** frpc should be able to reconnect like normal **Additional information you deem important (e.g. issue happens only occasionally):** I am new at Go, but I suspect the problem is because of this: In server Service.RegisterControl, you do ``` ctl := NewControl(ctx, svr.rc, svr.pxyManager, svr.pluginManager, svr.authVerifier, ctlConn, loginMsg, svr.cfg) if oldCtl := svr.ctlManager.Add(loginMsg.RunId, ctl); oldCtl != nil { oldCtl.allShutdown.WaitDone() } ctl.Start() ``` In my situation I don't think ctl.Start() is ever called because oldCtl.allShutdown.WaitDone() is hanging. oldCtl.allShutdown.WaitDone() is: ``` func (s *Shutdown) WaitDone() { <-s.doneCh } ``` Is it true that a channel can block indefinitely if the TCP connection is dead? Is it possible to time it out? Thanks!
gitea-mirror commented 2026-05-05 12:55:21 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Jun 5, 2020):

You can check if your log has client exit success message? It means your old control was stopped and allShutdown.Done() has been called.

So allShutdown.WaitDone() will not be blocked.

Set log_level to debug to see more info. You may also see if your client relogin success from logs of frpc.

<!-- gh-comment-id:639261821 --> @fatedier commented on GitHub (Jun 5, 2020): You can check if your log has `client exit success` message? It means your old control was stopped and `allShutdown.Done()` has been called. So `allShutdown.WaitDone()` will not be blocked. Set log_level to `debug` to see more info. You may also see if your client relogin success from logs of frpc.
gitea-mirror commented 2026-05-05 12:55:22 -06:00
Author
Owner
Copy link

@keyoti commented on GitHub (Jun 11, 2020):

You can check if your log has client exit success message? It means your old control was stopped and allShutdown.Done() has been called.

It is logging client exit success for some clients at some times. But I just reproduced the problem and for my client it is not logging that.

Set log_level to debug to see more info. You may also see if your client relogin success from logs of frpc.

I set it to trace and this is what I am seeing right now on my server and client:

FRPS:

ubuntu@ip-172-31-x-x:~/goprojects/bin$ sudo tail frps.log -f | grep 666f
2020/06/11 04:32:41 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:35650] version [0.33.0] hostname [] os [windows] arch [amd64]
2020/06/11 04:32:41 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae]
2020/06/11 04:33:11 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:37224] version [0.33.0] hostname [] os [windows] arch [amd64]
2020/06/11 04:33:11 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae]
2020/06/11 04:33:41 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:38892] version [0.33.0] hostname [] os [windows] arch [amd64]
2020/06/11 04:33:41 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae]
2020/06/11 04:34:11 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:40132] version [0.33.0] hostname [] os [windows] arch [amd64]
2020/06/11 04:34:11 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae]

FRPC:

2020/06/10 21:27:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...
2020/06/10 21:27:50 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached
2020/06/10 21:28:10 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...
2020/06/10 21:28:20 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached
2020/06/10 21:28:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...
2020/06/10 21:28:50 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached
2020/06/10 21:29:10 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...
2020/06/10 21:29:20 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached
2020/06/10 21:29:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...
2020/06/10 21:29:50 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached
2020/06/10 21:30:10 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...
2020/06/10 21:30:20 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached
2020/06/10 21:30:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server...

I will try to debug further tomorrow, hopefully I can see on the client what is happening.

<!-- gh-comment-id:642401017 --> @keyoti commented on GitHub (Jun 11, 2020): > You can check if your log has client exit success message? It means your old control was stopped and allShutdown.Done() has been called. It is logging `client exit success` for some clients at some times. But I just reproduced the problem and for my client it is not logging that. > Set log_level to debug to see more info. You may also see if your client relogin success from logs of frpc. I set it to trace and this is what I am seeing right now on my server and client: FRPS: ``` ubuntu@ip-172-31-x-x:~/goprojects/bin$ sudo tail frps.log -f | grep 666f 2020/06/11 04:32:41 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:35650] version [0.33.0] hostname [] os [windows] arch [amd64] 2020/06/11 04:32:41 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae] 2020/06/11 04:33:11 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:37224] version [0.33.0] hostname [] os [windows] arch [amd64] 2020/06/11 04:33:11 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae] 2020/06/11 04:33:41 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:38892] version [0.33.0] hostname [] os [windows] arch [amd64] 2020/06/11 04:33:41 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae] 2020/06/11 04:34:11 [I] [service.go:521] [666f8df9186830ae] client login info: ip [172.31.x.x:40132] version [0.33.0] hostname [] os [windows] arch [amd64] 2020/06/11 04:34:11 [I] [control.go:289] [666f8df9186830ae] Replaced by client [666f8df9186830ae] ``` FRPC: ``` 2020/06/10 21:27:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... 2020/06/10 21:27:50 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached 2020/06/10 21:28:10 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... 2020/06/10 21:28:20 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached 2020/06/10 21:28:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... 2020/06/10 21:28:50 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached 2020/06/10 21:29:10 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... 2020/06/10 21:29:20 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached 2020/06/10 21:29:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... 2020/06/10 21:29:50 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached 2020/06/10 21:30:10 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... 2020/06/10 21:30:20 [W] [service.go:187] [666f8df9186830ae] reconnect to server error: i/o deadline reached 2020/06/10 21:30:40 [I] [service.go:184] [666f8df9186830ae] try to reconnect to server... ``` I will try to debug further tomorrow, hopefully I can see on the client what is happening.
gitea-mirror commented 2026-05-05 12:55:23 -06:00
Author
Owner
Copy link

@keyoti commented on GitHub (Jun 11, 2020):

Ok, I'm sorry it seems to only be present in my fork, because I added to client admin API the ability to close proxies; The reconnect issue is only present when there are no proxies in use.

So I will figure it out, but in case it is of any use to anyone here is how I remove proxies in client/admin_api.go

func (svr *Service) apiCloseProxy(w http.ResponseWriter, r *http.Request) {
	var (
		buf []byte
		res GeneralResponse
	)
	defer func() {
		log.Info("Http response [/api/closeProxy]: code [%d]", res.Code)
		buf, _ = json.Marshal(&res)
		w.Header().Set("Content-Type", "application/json")
		w.Write(buf)
	}()

	getParams := r.URL.Query()

	log.Info("Http request: [/api/closeProxy]")

	mProxyName := "web-" + getParams.Get("s")

	svr.ctl.sendCh <- &msg.CloseProxy{
		ProxyName: mProxyName,
	}

	stopproxy := svr.ctl.pm.GetProxies()[mProxyName]
	if stopproxy != nil {
		stopproxy.StopWithNoRestart()
	}

	res.Code = 200
	res.Msg = "OK"
	return
}
<!-- gh-comment-id:642977499 --> @keyoti commented on GitHub (Jun 11, 2020): Ok, I'm sorry it seems to only be present in my fork, because I added to client admin API the ability to close proxies; The reconnect issue is only present when there are no proxies in use. So I will figure it out, but in case it is of any use to anyone here is how I remove proxies in client/admin_api.go ``` func (svr *Service) apiCloseProxy(w http.ResponseWriter, r *http.Request) { var ( buf []byte res GeneralResponse ) defer func() { log.Info("Http response [/api/closeProxy]: code [%d]", res.Code) buf, _ = json.Marshal(&res) w.Header().Set("Content-Type", "application/json") w.Write(buf) }() getParams := r.URL.Query() log.Info("Http request: [/api/closeProxy]") mProxyName := "web-" + getParams.Get("s") svr.ctl.sendCh <- &msg.CloseProxy{ ProxyName: mProxyName, } stopproxy := svr.ctl.pm.GetProxies()[mProxyName] if stopproxy != nil { stopproxy.StopWithNoRestart() } res.Code = 200 res.Msg = "OK" return } ```
gitea-mirror commented 2026-05-05 12:55:24 -06:00
Author
Owner
Copy link

@fatedier commented on GitHub (Jun 12, 2020):

@keyoti Maybe we can support add, update, delete proxies API in the future.

Now frpc only support reload proxies configures by configuration file. The simple way to do this is to translate add, update, delete operation to modify configurion file and call reload API. So frpc will compare the difference and do corresponding operations.

<!-- gh-comment-id:643047066 --> @fatedier commented on GitHub (Jun 12, 2020): @keyoti Maybe we can support `add, update, delete` proxies API in the future. Now frpc only support reload proxies configures by configuration file. The simple way to do this is to translate `add, update, delete` operation to modify configurion file and call reload API. So frpc will compare the difference and do corresponding operations.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
new
master
copilot/review-pull-request-5198
v0.68.1
v0.68.0
v0.67.0
v0.66.0
v0.65.0
v0.64.0
v0.63.0
v0.62.1
v0.62.0
v0.61.2
v0.61.1
v0.61.0
v0.60.0
v0.59.0
v0.58.1
v0.58.0
v0.57.0
v0.56.0
v0.55.1
v0.55.0
v0.54.0
v0.53.2
v0.53.1
v0.53.0
v0.52.3
v0.52.2
v0.52.1
v0.52.0
v0.51.3
v0.51.2
v0.51.1
v0.51.0
v0.50.0
v0.49.0
v0.48.0
v0.47.0
v0.46.1
v0.46.0
v0.45.0
v0.44.0
v0.43.0
v0.42.0
v0.41.0
v0.40.0
v0.39.1
v0.39.0
v0.38.0
v0.37.1
v0.37.0
v0.36.2
v0.36.1
v0.36.0
v0.35.1
v0.35.0
v0.34.3
v0.34.2
v0.34.1
v0.34.0
v0.33.0
v0.32.1
v0.32.0
v0.31.2
v0.31.1
v0.31.0
v0.30.0
v0.29.1
v0.29.0
v0.28.2
v0.28.1
v0.28.0
v0.27.1
v0.27.0
v0.26.0
v0.25.3
v0.25.2
v0.25.1
v0.25.0
v0.24.1
v0.24.0
v0.23.3
v0.23.2
v0.23.1
v0.23.0
v0.22.0
v0.21.0
v0.20.0
v0.19.1
v0.19.0
v0.18.0
v0.17.0
v0.16.1
v0.16.0
v0.15.1
v0.15.0
v0.14.1
v0.14.0
v0.13.0
v0.12.0
v0.11.0
v0.10.0
v0.9.3
v0.9.2
v0.9.1
v0.9.0
v0.8.1
v0.8.0
v0.7.0
v0.6.0
v0.5.0
v0.3.0
v0.2.0
v0.1.0
Labels
Clear 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

Mirrored from GitHub Pull Request

  
question

   
todo
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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#1454
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?