Two nodes (both Windows machines, local network) newly set up.
Very slow to sync, once apparently synced rather than showing both “Up to Date” node A (“Up to Date”) shows endless "Syncing (100%) on node B, while node B has multiple lines:
[C7MZ4] INFO: Puller: final: invalid argument
on console, interspersed by the occasional
[C7MZ4] INFO: Folder isn’t making progress. Pausing puller for 1m0s.
What gives?
Log is similarly full of hundreds of lines like this.
Checking manually the sync status appears to show a difference of 2109 files still in an archive of just over a million.
Restarting node B makes syncthing do lots of new work, and slowly seem to start grinding through the remaining files at a painfully slow 100 KiB per second, meanwhile bizarrely showing 18% sync status (it was 100% before, recall) on node A.
After about 20 minutes of this, with the sync status of B slowly creeping up as shown on node A, we arrive again at the point where it is endlessly showing 100%.
Despite this 20 minutes of hard work from both nodes (CPU shooting up to 100%, “lots” of file transfer at the painfully slow 100 KiB/s), absolutely nothing has changed in terms of the number of files at each node - still the same absolute numbers, and same difference of 2109 files, and we are back to the endless “Puller: final: invalid argument” on node B console/log.
The issue seems to be to do with symlinks. What I would like is for syncthing to ignore symlinks entirely, as if they aren’t there. Is there an option I can set in the config file to enforce this behaviour?
Well, I’m trying to figure that out. It was stalling on certain symlinks, with a message that it couldn’t find the file. When I deleted those symlinks and then recreated them on both sides of the sync pointing to the same local path, the sync seemed to complete successfully, so I did not run the diagnostics you suggested.
Right now I am having a different issue, which I need to resolve more urgently. When I start syncthing as a Windows service (using the instructions at http://docs.syncthing.net/users/autostart.html) it will not connect with any nodes, which I find very strange. I can connect using the web GUI, which shows all nodes as ‘Disconnected’, upon opening the log file I see no entries newer than when the Windows service was created.
Which log file do you open? Syncthing will not log anything to do with services, which implies you’re opening a log file created by some other tool? Syncthing’s log file lives at %LOCALAPPDATA%\Syncthing\Syncthing.log.
Yes that’s the log I opened. I do not believe syncthing ‘knows’ it is being run as a service. The service manager nssm creates the service and it is started automatically.
The timestamp for the log file shows as more than 1 hour ago, which it means it hasn’t been touched in the last hour, right? And yet syncthing is currently running, and I can connect to it with the web gui. Isn’t that pretty strange?
Not really. You’re probably running Syncthing as a local admin / system (which, by the way, is a terrible idea). The local admin will have their own value for %LOCALAPPDATA%, meaning that Syncthing will use a different home folder.
OK, that makes sense, except for two things: I followed the instructions on the doc site, and the web GUI shows the folder that I created earlier when running the exec from the command line.
say “At the Log On tab you can enter a username and password for the
user to run Syncthing as. This user needs to have access to all the
synced folders. Usually, you can leave it as the System account.” ?
Not questioning you saying it is a terrible idea - I thought that myself when I read the instructions. But I followed them anyway.
The doc page says “At the Log On tab you can enter a username and password for the
user to run Syncthing as. This user needs to have access to all the
synced folders. Usually, you can leave it as the System account.” implying that you may have left it as a System account.
I’m honestly not sure on the “the web GUI shows the folder that I created earlier” aspect. No logging and inability to connect would imply that Syncthing is using a different log file and different key pair, which would explain a few things…
Those instructions on using NSSM are user-contributed. I added the huge warning at the top of that section, but running Syncthing as a service does have a single viable use-case: running Syncthing on a headless server which users will not log into directly (only admin), and administered by someone smart enough to make sure that it’s secure (https, secure password, etc).
Sadly most people setting Syncthing up as a service do so because they don’t know the problems, and aren’t aware that starting Syncthing on login is a much better approach in almost all situations for multiple reasons. I’ve had numerous “educational” discussions with people about this in here and on GitHub…
Yes, that would explain a few things. I’ve done this a few times, and always used my own user account to create the service, but since having issues, decided to try following the instructions verbatim.
I will now delete the service and re-create using my own login details. I understand the risks…
