Syncthing stops working after resume from suspend

Support
1

Hi, I’m having an issue where Syncthing stops working on my laptop after it has been sleeping for a while.

Manually restarting the service does fix it, at least until it happens again later. Suspending and immediately resuming the machine doesn’t break, it’s only after it has been sleeping for a while. Searching around there apparently used to be an advanced option to restart the Syncthing service after resuming, but it appears to no longer exist.

When it’s not working it looks like this:

Screenshot 2024-11-18 060554
Screenshot 2024-11-18 0605541184×921 37.5 KB
The network connection and Syncthing services on the other machines are up despite what it says. “Last seen: never” also doesn’t make much sense.

Log has a bunch of entries saying this: “024-11-18 06:07:29 Listen (BEP/tcp): TLS handshake: read tcp [fe80::769f:c6e2:1296:6018%Wi-Fi]:22000->[fe80::2e0:4cff:fe1f:b2d%Wi-Fi]:22000: wsarecv: An existing connection was forcibly closed by the remote host.”

Running Syncthing 1.28.0 on Windows 11.

2

The GUI looks completely stuck.

Can you try following the steps described in Syncthing process stalled after Windows hibernation - #15 by calmh?

3

The STPROFILER thing doesn’t seem to be working.

If I run:

set STPROFILER=localhost:9090
syncthing --debug-profiler-listen ($STPROFILER)

I get (in the log):

listen tcp: address ($STPROFILER): missing port in address

If I change the variable to windows cmd style:

syncthing --debug-profiler-listen (%STPROFILER%)

I get:

listen tcp: lookup tcp/9090): unknown port

I get the same thing if I run it with the hostname/port directly in the parameter

syncthing --debug-profiler-listen (localhost:9090)

listen tcp: lookup tcp/9090): unknown port
4

Try without the ()

5

Dropping the () got the debug page working, thanks. I’ll leave it running like this and see if the debug page loads when the service breaks.

1 Like
6

Alright, it froze again today. Debug page loaded fine. I’ll attach its output though I guess you’re mainly interested on seeing if it loaded? goroutine.txt (55.4 KB)

Doesn’t seem like the UI is completely frozen anyway. I can still restart the service and view the logs through the actions pulldown menu.

Judging by the repeated log entries like the one I put in my original post, it looks to me like it might be repeatedly trying to use a closed tcp connection rather than establishing a new one?

1 Like
7

I suspect this is a deadlock from trying to promote a connection that is also being closed at the same time. I could see that being related to waking after suspend somehow given that we’ll have x connections from before that are now all dead and need closing at the same time we are adding new connections and promoting stuff…

That said, I’m not sure why a new connection (being promoted) would also be the one being closed…