Hello
I have 2 computers, linked by syncthing, one linux on AWS which generates a few small CSV files once a day. One mac laptop at home which receives these files when online.
About every other day, syncing fails, and will not resume. Then I find a few temporary files on the laptop, and by removing the temp files, syncing resumes immediately.
I am at my wits end. I could, of course, script deleting the temp files, but that seems silly. There must be a more elegant solution.
I do know things fail with an error, but I could not find it, but alas, I am not a syncthing expert.
No error on the web interface on either machine.
The mac apparently only sends the logs to stout, visible in the gui, and no errors (as far as I can tell) since machine was rebooted yesterday. If it keeps logs, I have idea where they are.
I cannot find where the logs on the linux are, the recommended command does not tell me
syncthing -paths 1 ↵
Log file:
-
and the gui only has the most recent 500 or so entries, all too recent.
But I will endeavour to chase this down.
As it often creates temp filenames with hash type names, will happen soon, so will monitor logs then.
I am not using syncthing-macos. Having syncthing produce a log to a file is not as easy as one would wish, an easy command line option, yes, but not exactly obvious how it is invoked in the first place. On linux delving into the intricacies of systemd and mac bypass the gui.
Then I very much suggest to use -logfile=default when starting Syncthing, which will log to syncthing.log in the home/data dir of Syncthing (with rotation and such) - regardless of -no-restart since quite a while.
Usage:
syncthing [options]
Options:
...
-logfile="-" Log file name (see below).
...
Logging always happens to the command line (stdout) and optionally to the
file at the path specified by -logfile=path. In addition to an path, the special
values "default" and "-" may be used. The former logs to DATADIR/syncthing.log
(see -data-dir), which is the default on Windows, and the latter only to stdout,
no file, which is the default anywhere else.
But of course always feel free to improve the HTML docs!
And in general the answer to “why isn’t …” isn’t that it’s a conspiracy to make everyone unhappy, but probably that we forgot, didn’t get around to it, or didn’t have the energy at the time and then forgot.
I have the logs on, but get files like those below created, with “OK” in them, and syncthing is stops syncing until I remove them. Nothing shows up in the syncthing logs.
any idea ?
-rw-rw-r-- 1 jond staff 2B 20 Jan 01:02 15df2ebb-7e86-4614-80f4-c1fe70bab243.3
-rw-rw-r-- 1 jond staff 2B 19 Jan 01:02 15df2ebb-7e86-4614-80f4-c1fe70bab243.2
-rw-rw-r-- 1 jond staff 2B 18 Jan 01:02 15df2ebb-7e86-4614-80f4-c1fe70bab243.1
-rw-rw-r-- 1 jond staff 2B 17 Jan 01:02 15df2ebb-7e86-4614-80f4-c1fe70bab243
Syncthing doesn’t create files, unless they are synced from a connected remote device. These either originate from other software on your local device or from a remote device.
What do you mean by stops syncing? Are there failed items displayed in the web UI?
Describe what you do and see, do not use vague concepts in support requests - it makes it very hard to help you.
Nothing? Then logging doesn’t work and that’s the first thing to fix.
Fair enough, I am not a syncthing expert and do apologise for not being systematic enough
I did get this in the logs, every few seconds
2021-01-25 07:59:12 Connected to myself (AELIBGT-57X53WK-H2FG44Z-YBXGH7R-3WF6LS4-2JSDJ7T-T24GUWI-WR756QA) at [::]:22000-10.211.55.2:22000/quic-client/TLS1.3-TLS_AES_128_GCM_SHA256 - should not happen
so. at 1am every day, Linux on AWS runs a cron script that makes some small csv files
some days I get files with hash names, and string “OK” in them. My script does not do that, but I can’t figure out if syncthing has anything to do with it either. nothing shows up in the logs on the linux. Will turn of syncthing to see if there is a connection.
-rw-rw-r-- 1 jond staff 2B 20 Jan 01:02 15df2ebb-7e86-4614-80f4-c1fe70bab243.3
when I open my laptop in the morning, those hash name files get synced over, but not the csv files
log on the laptop fills with
2021-01-25 07:59:12 Connected to myself (AELIBGT-57X53WK-H2FG44Z-YBXGH7R-3WF6LS4-2JSDJ7T-T24GUWI-WR756QA) at [::]:22000-10.211.55.2:22000/quic-client/TLS1.3-TLS_AES_128_GCM_SHA256 - should not happen
and
2021-01-25 09:36:45 Puller (folder “data” (data), item “update/csv/TELAVIV100.sync-conflict-20210125-093630-MFCUDRN.csv”): syncing: file modified but not rescanned; will try again later
2021-01-25 09:36:45 “data” (data): Failed to sync 2 items
2021-01-25 09:36:45 Folder “data” (data) isn’t making sync progress - retrying in 1m23s.
I delete the hash name files, and all syncs OK. I delete all the sync-conflict files
The “connected to myself” lines you can ignore
Sync failures on some files do not prevent syncing of other files, so that can’t be the entire problem. The next time this occurs, please check the web UI on both sides and take screenshots and post them here.
Then a folder should have status “Failed Items” and list the same errors you see on the log. However on the screenshot all folders are up-to-date.
The asymmetry is that Sonja thinks that siggi is syncing, but siggi says that all it’s folders are up-to-date (not syncing). What folders are shown as syncing when you expand siggi (syncing) and click on the out-of-sync items? If you expand those folders on both siggi and sonja, do the local and global states match (screenshots).
I found out why it says out of sync following your suggestion! Linux on Amazon used to sync a folder to laptop at home. I stopped syncing a folder on amazon side, but laptop still has folder, it syncs it to other machines, and still thinks it should be syncing it to amazon machine. i’ll take care of that
It seems to be repeatedly restarting syncthing on the linux, it that normal? logs showed
WARNING: Database schema: database is closed
As to why syncing fails until I remove the files with the hash file names, still investigating. Will stop syncthing on amazon and manually start it to sync, to see if these hash file names have anything to do with syncthing
again, thanks so much for staying with me, its a weird problem I have and I dont know enough (yet) about syncthing to diagnose properly
