I have syncthing and syncthing-inotify installed and use systemd.
As the syncthing service pulls in the inotify service, it looks to me that, unless I do a bit of fiddling, if I were to enable the built-in fswatcher, I would be watching all folders twice.
This doesn’t seem to be useful, so I haven’t tried it.
BUT, does either or both the internal and external watcher recognise the other with one deferring to the other? If not, this might be useful to ease the transition.
At the moment, no, which is one reason why it’s disabled by default in Syncthing. There are a number of finishing touches to apply, both in terms of interaction with external things and in terms of GUI, notifications, etc.
As Jakob said, it still has some rough edges. However you can switch to the builtin watcher without fiddling with the systemd scripts: Just uninstall syncthing-inotify. The service only “wants” syncthing-inotify, i.e. if it isn’t there, it will still start.
Yes.
In my order of increasing complexity…
Then my brain hurt, so I decided it was too much of a palaver for now.
1, 3 and 4 sound potentially painful. 2 seems pretty benign and should be the only necessary action. Sure you can also just stay - I hope you understand that I advertise changing 
de gustibus…, but 2 feels more like a permanent solution, while 1 seems like a quick try.
Not logical…
You could also just disable the systemd service. Dont remember the exact command, but it should be easy to find.
Ah yeah sure, I was thinking this was about not interacting with systemd, because that’s the usual problem 
If you don’t mind that, rescanning the syncthing-inotify service or commenting the wants line in the syncthing service is the way to go.
@Nutomic, disabling won’t work - it isn’t enabled anyway.
Enabling just makes a service start automatically at startup.
syncthing-iotify is started by syncthing (wants), and starts whether the syncthing service is enabled or not when the syncthing service starts
The feature to persuade me to switch is monitoring by folder. Some folders monitored by periodic scanning and others by file watching.
Horses for courses.
Well then you got to switch: You can adjust per folder the normal rescan intervals, whether to watch and how long to delay between a change and the actual scan.
# systemctl disable syncthing-inotify@USER.service
Replace USER with the user under whom syncthing is running.
For user instances use
$ systemctl --user disable syncthing-inotify.service
As David already mentioned, this wont change anything when using the default Syncthing service: Syncthing-inotify is started due to a “Wants” dependency of the syncthing service, which happens regardless of whether you enable it or not.
Jou. As the author of that Wants thing in the syncthing service file: Should we remove it in the near future?
It is possible to remove Wants wit with a dropin:
# systemctl edit syncthing@....
or
$ systemctl --user edit syncthing
Than overwrite the Wants:
[Unit]
Wants=
I think we should remove that when this feature has survived a little bit in the wild and the web UI and documentation is updated for it - no need to spook users before that. And I suspect overriding the Wants doesn’t work, as you can specifiy multiple Wants, so it wouldn’t be clear which one an empty Wants should override.
We should, at some point. But this is all a little premature. I know there is a great desire for a built in fs watcher, and it’s awesome that we have it integrated - but it really is just there for testing and there are rough edges. We need to bring in the GUI feature, figure out an upgrade path for these things, and so on.
Just mask the service, job done…
mask NAME...
Mask one or more units, as specified on the command line. This will
link these unit files to /dev/null, making it impossible to start
them. This is a stronger version of disable, since it prohibits all
kinds of activation of the unit, including enablement and manual
activation. Use this option with care. This honors the --runtime
option to only mask temporarily until the next reboot of the
system. The --now option may be used to ensure that the units are
also stopped. This command expects valid unit names only, it does
not accept unit file paths.I think the best solution is for syncthing-inotify to monitor Syncthing’s config, and to disable its watcher if the watcher is enabled in Syncthing. That way it automatically disables itself as people enable the built-in watcher, but doesn’t suddenly disappear for everyone.
When the watcher has been around in Syncthing for a while, you can start either automatically enabling the built-in watcher, or prompting the user (somehow) to enable it, before finally being removed from Wants at the same time that syncthing-inotify is deprecated, many months from now.
(This is what I’m in the process of doing for SyncTrayzor).
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.