You are probably better off restarting syncthing after you kill inotify as it won’t scan things for a while (as inotify defers scans based on the assumption that it doesn’t get killed).
Syncthing has no control over inotify daemon, and inotify daemon does not have an API, so I think killing is the only way.
It’s the time passed to syncthing-inotify with the flag -delay-scan which defaults to 1h. After that, the rescan interval from folder configuration in syncthing UI “takes over” again.
I looked for the a “delay scan” option in the syncthing GUI, but couldn’t find it. How does the user configure this option to be passed to syncthing-inotify?
Do I have this right in usual operation with inotify (actually this is likely wrong, but perhaps it’s some text to copy paste to speed your answer):
Start inotify watcher
Do startup scan
Wait the -delay-scan interval (while receiving from inotify)
Wait the “rescan interval” (or just the remainder?) then do a full scan
Go to Step 3
Or does syncthing-inotify do a full scan on behalf of syncthing?
Also, is the only difference that if inotify is killed, there will be no notifications during the remainder of step 3?
I’m a bit bamboozled by the different interactions in the usual case, and then the additional complexity should the inotify be killed.
What Syncthing GUI are you talking about the “normal” GUI (the web ui) doesn’t have any params for inotify, as syncthing-inotify is a different and optional binary.
When inotify starts (after syncthing is already running), it will just watch the folders for changes. When it detects a change, it will tell syncthing to scan that change and wait for 1h (or the -delay-scan) for the next scan.
If you then kill inotify, syncthing will wait the 1h, then scan, then go back to the configured rescan interval (default 1m).
I would try: kill inotify, unmount the hdd, restart inotify.