Two of my Synology servers are updated to v1.4.0-rc.7 and on one of the server it seems a scanning problem. First some pics:
It means, on one of the server the content is double and the difference also is shown on pic 3. In this moment a “syncthing -reset-deltas” is running on the server regarding pic 2.
Any ideas?
No idea how it happens. On the side with double the items, you can start with env var STRECHECKDBEVERY=0 set and see if that fixes the problem
what is the whole command of that? is like
/var/packages/syncthing/target/bin/syncthing env var STRECHECKDBEVERY=0 set
or with which usage?
I try to work with
/var/packages/syncthing/target/bin/syncthing -reset-database
but without effect.
I found that around 1/4 of the peers simply show double what is actually included. The pics are comparable, as shown, only with other values.
To set an env var you put it before the command, i.e. STRECHECKDBEVERY=0 syncthing ....
You get the same thing when starting with -reset-database? Then please do so again and run with STTRACE=db syncthing -reset-database 2>&1 >path/to/place/the/huge/logfile.log. Be warned, the logfile will be huge, that’s expected and necessary. Then please make that file available through whatever service you like (we could actually even setup a syncthing folder for that 
).
It doesnt run. If I use
/var/packages/syncthing/target/bin/STTRACE=db syncthing -reset-database 2 >&1 > /path/Syncthing_log_Synology_DS1815.log
I got
-ash: line 69: /var/packages/syncthing/target/bin/STTRACE=db: No such file or directory
Some is strange, because if I run
/var/packages/syncthing/target/bin/syncthing -upgrade-check
I got
21:38:47 INFO: No upgrade available (current “v1.4.0-rc.7” >= latest “v1.3.4”)
If I run
/var/packages/syncthing/target/bin/syncthing -reset-database
nothing happen.
It has to be STTRACE=db /var/packages/syncthing/target/bin/syncthing ... And I doubt you really want to log to /path/Syncthing_log_Synology_DS1815.log. If you don’t have any data/home directory, at least use a dir that already exists (/media, /var, /opt, …).
It seems, there is no action regarding the parameter “-reset-database”
I deleted the peers with double values and reconnect them. So such peers are reworked for now, but I´m not sure, if the values I see in the GUI for each peer are right. It seems so, if I compare with the folders in the Synology DSM, so is more or less the same, I have to consider, I use Ignore Patterns.
All seems right now, but I wonder me during the last days, because if I upgrade from v1.3.4 to v1.4.x, the whole no. of files increases from about 1,38 Mio to now 1,79 Mio. I doent know why.
…I think I found the difference. Two peers on both servers have now 820 k files and in real there are about 410 k files.
Therefore I want to use the database reset to be sure of all.
After rework my first server with RC.x, I´m back about to 1,38 Mio files, 109 T folders and 2,12 TB. The same status I had with v1.3.4.
What is the reason, why the upgrade to v1.4.0-rc.x make such double values?
I noticed that some of the peers that are connected to the server’s main directories were affected. As far as I can understand, none of the subdirectories were affected.
I don’t know. That’s why I asked if you can indeed reproduce and then get logs:
Please consider the advice you are given and if you decide to not follow it, please say so, ideally giving a reason. Even if just “too cumbersome, no time” - that’s clearly perfectly valid. It then prevents the person giving advice (me) spending more time for nothing. Thanks.
I know, but it doesn´t run. I try different possibilities, but there was no reaction and the log was created in the setted folder, but was still empty.
I executed the command with the corrections directly in the storage path of Syncthing, I tried that with PuTTY, with WinSCP, both with root rights, to do nothing. I have already commented on this above.
It probably was just fine, the command just logs to the file only, i.e. you see nothing happening on the command line. To see what’s happening use tee, i.e. adjust your command line to something like this: STTRACE=db /var/packages/syncthing/target/bin/syncthing ... 2>&1 | tee ..., i.e. replace > with | tee.
I run directly in the “bin” folder, result:
/var/packages/syncthing/target/bin$ STTRACE=db syncthing -reset-database 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log
-ash: line 79: syncthing: command not found
The same as before. Also, if I run
/var/packages/syncthing/target/bin$ syncthing -reset-database
-ash: line 81: syncthing: command not found
If I run in the root folder of the server:
/$ STTRACE=db /var/packages/syncthing/target/bin/syncthing -reset-database 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log
(no response)
If I test another command:
/$ STTRACE=db /var/packages/syncthing/target/bin/syncthing -upgrade-check
2020/02/25 09:16:49.583513 main.go:475: INFO: No upgrade available (current “v1.4.0-rc.7” >= latest “v1.3.4”).
Why one command is working and the other not? This is not clear.
How long did you wait? There’s nothing wrong with that command as far as I can see. tee does buffer the output, so that might just be the reason it takes a while.
If running a file in the current directory, you need to prepend ./, i.e. /var/packages/syncthing/target/bin$ STTRACE=db ./syncthing -reset-database 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log
Okay I test the last part.
I´m waiting for minutes and normally I can not close the comand window of WinSCP until a command is not done. And also now, since 70 Minutes after my further test in this morning, the
/volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log
was modified from the command, but still is empty.
Does that mean the command exits immediately?
Also you can try the following instead:
STTRACE=db /var/packages/syncthing/target/bin/syncthing -reset-database -log-max-size=0 -logfile=/volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log
Yes. I try now with PuTTY as follow:
root@Synology:/var/packages/syncthing/target/bin# ./syncthing -reset-database
root@Synology:/var/packages/syncthing/target/bin#
The second line is coming in approx. 1 second.
For tests I also have the Kastelo installation running, which have the same issue
root@Synology:/var/packages/syncthing.net/target/bin# ./syncthing -reset-database
root@Synology:/var/packages/syncthing.net/target/bin#
The second line is coming in approx. 1 second.
