Fresh setup with 2 devices, sync stuck with no progress

I doubt connection attempts could be to do with this. Is this something youbwere able to reproduce?

I will try next as it’s easy to let it scan and sync over again…

Same thing:

We updated goleveldb in 1.3.1 and it feels like this is an issue that happens roughly since about that time

1 Like

Yes, seems to be my issue, too. I didn’t find the repoducer yet. Just rescanned after a db reset and ot worked again.

I’ve ran some stress tests now for a couple of hours doing continuous database updates and checking for this issue in parallel and haven’t found anything on my systems. So it’s not totally systematic at least.

1 Like

Do logs ever contain Database failed to stop within 10s?

I reran and tried sth I did last time with my fresh sync cluster. While the initial scan took place on the source for /path/Install, I created another Syncthing folder pointing to a subfolder of it (Install2). Left the nested-folder unshared, let it scan 50% and then deleted it via Syncthing’s Web UI. The main folder /path/Install was initially shared to and accepted by the destination while scanning and already beginning transferring data while scan was in progress. I “unfortunately” could not reproduce the index problems. The sync went well over. I’ve also captured logs, nothing special in there - because of successful sync.

The only messages I’ve found suspicious on source.log is:

2020-02-03 14:20:17 Adding folder "Install2" (ppukr-qztcq)
2020-02-03 14:20:17 No stored folder metadata for "ppukr-qztcq": recalculating
2020-02-03 14:20:18 Ready to synchronize "Install2" (ppukr-qztcq) (sendreceive)
2020-02-03 14:20:51 Adding folder "Acrylic" (s5yhr-7wbsp)
2020-02-03 14:20:51 No stored folder metadata for "s5yhr-7wbsp": recalculating
2020-02-03 14:20:52 Ready to synchronize "Acrylic" (s5yhr-7wbsp) (sendreceive)
2020-02-03 14:20:53 Completed initial scan of sendreceive folder "Acrylic" (s5yhr-7wbsp)
2020-02-03 14:21:12 Failed initial scan of sendreceive folder "Install2" (ppukr-qztcq)

Full logs of source and destination (fresh setups) for reference - if they are of any use. Else ignore.

destination.log (3.4 KB) source.log (4.4 KB)

This is every stop, for me.

That’s not ok. If you enable the app debug facility, is there also a service which fails to terminate in a timely manner? (that should probably be changed to log at info or even warning level anyway)

Yeah I was going to troubleshoot at some point. On mobile right now unfortunately.

First start with a new config dir, ^C after a while, fails to shutdown:

jb@kvin:~ % STTRACE=app syncthing -home tmp/asdasdasd
[monitor] 2020/02/04 08:25:20.163238 utils.go:56: INFO: Default folder created and/or linked to new config
[start] 2020/02/04 08:25:20.180246 main.go:544: INFO: syncthing v1.3.4-rc.1+17-g9de8602d5-dedupblocklist "Fermium Flea" (go1.13.3 darwin-amd64) 2020-01-22 07:27:01 UTC
[start] 2020/02/04 08:25:20.180353 utils.go:33: INFO: Generating ECDSA key and certificate for syncthing...
[WJIUS] 2020/02/04 08:25:21.722312 syncthing.go:332: INFO: My name is ""
^C[monitor] 2020/02/04 08:25:25.286605 monitor.go:153: INFO: Signal 2 received; exiting
[WJIUS] 2020/02/04 08:25:25.286687 relay_listen.go:121: INFO: Relay listener (dynamic+ shutting down
[WJIUS] 2020/02/04 08:25:25.666244 tcp_listen.go:87: INFO: TCP listener ([::]:22000) shutting down
[WJIUS] 2020/02/04 08:25:32.673225 service.go:67: INFO: Detected 1 NAT service
[WJIUS] 2020/02/04 08:25:42.676447 syncthing.go:369: WARNING: Database failed to stop within 10s
[WJIUS] 2020/02/04 08:25:42.676460 syncthing.go:372: INFO: Exiting
jb@kvin:~ %
1 Like

I’m observing a weird log line when syncing between two other devices, not related to the initial post. But this time, the sync seems to work okay.

Folder F shared between A+B (id “n4q4z-ohpfz”)

A: Windows 10-1903 x64, Syncthing v1.3.4

B: Linux amd64, Syncthing v1.3.4

A has a suspicious entry in the log:

2020-02-05 14:04:49 Syncthing should not run as a privileged or system user. Please consider using a normal user account.
2020-02-05 14:04:50 Stored folder metadata for "n4q4z-ohpfz" is 723h26m4.8138797s old; recalculating
2020-02-05 14:04:50 Index for nonexistent folder "n4q4z-ohpfz"

Maybe the log is related to the problem? I don’t see why the metadata should be old. Why do I get the log line “Index for nonexistent folder “n4q4z-ohpfz”” because of a non-paused folder which seems to be fully in sync between the two online devices A+B.

Going to build a windows stindex.exe …

go run build.go -goos windows -goarch amd64 build all

stindex.exe (9.9 MB)

A: Command line (Windows):

stindex --mode idxck "X:\index-v0.14.0.db" > "X:\stindex_result.log"

Hmmm… stindex this time doesn’t output anything which implies the database is okay. I expected it to show errors for device A (like it did in the initial post’s case between those linux devices). Not sure if we diagnose the “same” problem here.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.