sync regularly fails with temp files

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.

best, Jack in desperation

You haven’t provided any logs, screenshots or error messages, so I am not ever sure how to help you.

If things fail, they fail with an error message.

Fair enough. Sorry for the stupid question.

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.

again, sorry for the trouble, Jack

Are you using syncthing-macos?
@jerryjacobs How is the log handled there?

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.

Currently the log is written into the void for syncthing-macos. See

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.