Can I get syncthing to perform a final scan & sync as the (systemd) service is being stopped during system shut-down?
That would ensure that the latest state is available to any other machines that are online at that time.
I am sometimes using my syncthingctl tool (part of Syncthing Tray) for that:
syncthingctl-qt6 rescan-all && syncthingctl-qt6 wait-for-idle --timeout 1800000 --at-least 5000 && syncthingctl-qt6 --url https://url-to-remote-st-instance wait-for-idle --timeout 1800000 --at-least 5000 && systemctl poweroff
(I guess it would make sense to extend this to avoid having to connect to the remote instance directly. However, I don’t need this very often so I haven’t made that improvement yet. It would be a bit problematic anyway because if no (relevant) remote is connected the remote state will not be considered at all.)
2 Likes
Okay, so the syncthingctl-qt6 --url https://url-to-remote-st-instance wait-for-idle part of it will only be possible if the WebUI of the remote instance is publicly accessible, correct?
Is there no internal way for the local Syncthing instance to be sure that everything it has, has been sent? Is that not what a local idle status means? Because that’s all I want it to do; I don’t care if the remote is not idle due to some ongoing transfers from a third instance.
Correct.
Syncthing is aware of the remote completion. The official web UI shows this and so does Syncthing Tray. However, I think I’ve never implemented that for the syncthingctl-qt6 wait-for-idle.
How about the --all-devs option of wait-for-idle? Does that make sure all devices, including those that are remote, reach an idle state?
I guess I’ll have to check what the code does. However, chances are actually good that --all-devs includes the remote state. (And if not this should be fairly simple to implement.) Of course, as mentioned in my initial response, the relevant remote dev actually needs to be connected.
1 Like
After looking at the code I suppose --all-devs/--dev takes the remote completion into account. I guess I have never tested it, though.
You can apparently also specify --require-devs-connected to consider disconnected devs not idle (which might make sense to use with only a specific --dev).
I’ve just tested it and waiting for devs definitely incorporates the “synchronizing” state of a device - so it’ll wait until the remote device has finished the synchronization.
1 Like