Transfers are "immediate", failing to detect syncing with syncthingctl/API

[rieje]

I'm struggling to have a script/application detect that syncthing is changing state from "syncing" to "idle". My goal is to start such a script/application on system startup, wait a bit until it detects folders are idle, indicating sync is complete, then exits 0, signalling to e.g. autostart my text editor (Emacs/Neovim).

At first I tried polling at .1 seconds using the API:

curl -sk -H "X-API-Key: $apikey" -X GET "https://127.0.0.1:8384/rest/db/completion?folder=$folder_id" | jq .completion

but Syncthing always reports 100% completion. What happens after I create a 1GB file on the server to sync to the local machine is that it goes from showing no file to the 1GB file in an instant, which I assume is why it always show 100% completion (i.e. the file doesn't "grow" as it is syncing--it either shows up on the local machine as the full file or it hasn't "synced" yet. I'm sure my internet connection is not this fast--I get 11 MBps transfers between the systems. I also tested event API counterpart and it's the same story.

I tried syncthingctl:

watch -n 1 'syncthingctl status --dir ~/notes | grep -i status'
watch -n 1 fd output ~/notes
syncthingctl --wait-for-idle --at-least 5000 --timeout 300000

The first command always shows idle even when the second command shows from nothing to the 1GB file created. I adjusted the values of --at-least but to no avail. I have the web GUI opened on the side and don't see the syncing progress either (it probably shows "Syncing" for some milliseconds before "Up to Date", also reflecting what I'm experiencing. When I download a file with aria2 or yt-dlp, a file grows from bytes to gigabytes as you would expect but this is not the case with a

I suspect syncing completion % reporting has more to do with many files, so I copied 500M worth of low quality pictures and actually see "preparing to sync" for a brief second before seeing "idle" in the first command. However, the syncthingctl --wait-for-idle command is still useless for my purpose because setting a value too low means it exits before potentially even realizing a sync needs to be made and setting it too high means autostarting my applications too late). I guess what's true of a successful sync is when state is changed to idle within a time period, which the command is not capable of.

I'm on Linux. Any suggestions is appreciated.

[Martchus]

I have the web GUI opened on the side and don't see the syncing progress either (it probably shows "Syncing" for some milliseconds before "Up to Date", also reflecting what I'm experiencing.

If the web GUI doesn't show the folder as syncing then there's nothing syncthingctl can do for you. It basically just queries the same API as the web GUI. Possibly it has some extra bugs but certainly it is not better than the web GUI.

Note that I can not generally reproduce what you're describing. On the downloading end the relevant folder is in the synchronizing state as long as the download takes. On the uploading ends the relevant remote device is in the synchronizing state as long as it lacks behind the latest version (for whatever reason). This works reliably for me.

When files are changing continiously the change might not be immidiately detected by Syncthing. This is obviously because Syncthing only scans in certain invervals and even when file system watchers are enabled it makes totally sense for Syncthing to back off shortly instead of inefficiently picking up every little new chunk of data individually. Due to this a folder may appear idle when it in fact isn't. The --at-least option in syncthingctl is supposed to accommodate that.

Considering the official web GUI doesn't show the status correctly as well in your setup this seems to be a backend issue. My own insights are rather limited in that regard. So I suggest you file an issue on the core Syncthing project's issue tracker or ask in the official forum. Possibly you need to provide more details, though.

[rieje]

Thanks. I have found it's not really suitable to wait for until scan finishes to autostart applications for my specific case:

• Initial startup of Syncthing results in devices reporting as idle immediately before initial sync, so some arbitrary amount of time must be waited, which is prone to errors (as suggested by the --at-least option).

• In addition, starting syncthingctl or using the API immediately after systemctl --user syncthing results in failed connection, presumably because Syncthing is not ready. From my experience, need to wait 2-3 seconds after Syncthing is started in order to check the status.

• Triggering a manual scan will incorrectly report device as updated when it isn't, until ~8 seconds after (I have inotify enabled, but as you've mentioned, Syncthing still does polling for efficiency).

It would be nice for Syncthing to allow hooking up the event API immediately when it's ready and also for a manual scan to actually trigger a resync immediately.

[Martchus]

Initial startup of Syncthing …

I suppose that can indeed be. Until Syncthing knows there is something new to pull it thinks the folders are idle.

In addition, starting syncthingctl or using the API immediately after …

That's very much true. In Syncthing Tray I also have therefore a connect retry and it can suppress error message happening shortly after the unit gets activated. For this to be smoother Syncthing needed to signal systemd when it is ready but to my knowledge this hasn't been implemented yet.

Triggering a manual scan will incorrectly report device as updated …

Even with inotify there will always be a delay between a change happening and Syncthing processing it.

It would be nice for Syncthing to allow hooking up the event API immediately when it's ready

It will always need some time to start. You could go ahead and implement signaling systemd when the API is ready. This shouldn't be hard to do. Another Go project I know which already does this is Grafana so you could just check how Grafana is doing it. You can also mention this to upstream developers of Syncthing.

and also for a manual scan to actually trigger a resync immediately.

Maybe also note worth discussing with upstream Syncthing developers.