Database to upgrade to v1.4.0-rc.7

Is possible, that both installation SynoComm. and Kastelo on one server have influence of that? I don´t think so, but I´m not sure now. Otherwise, it seems, if such commands are running on your servers, at the end is a Synology specific problem. But in this case, I have no idea.

Strange for me is, that another command is running with the follow flow:


root@Synology:/var/packages/syncthing/target/bin# /var/packages/syncthing/target/bin/syncthing -upgrade-check

15:09:06 INFO: No upgrade available (current “v1.4.0-rc.7” >= latest “v1.3.4”).


root@Synology:/var/packages/syncthing/target/bin# syncthing -upgrade-check

-ash: syncthing: command not found


root@Synology:/var/packages/syncthing/target/bin# ./syncthing -upgrade-check

15:09:28 INFO: No upgrade available (current “v1.4.0-rc.7” >= latest “v1.3.4”).


root@Synology:/var/packages/syncthing/target/bin# cd /

root@Synology:/# /var/packages/syncthing/target/bin/syncthing -upgrade-check

15:09:32 INFO: No upgrade available (current “v1.4.0-rc.7” >= latest “v1.3.4”).

Same with Kastelo installation:

root@Synology:/var/packages/syncthing/target/bin# cd /var/packages/syncthing.net/target/bin/


root@Synology:/var/packages/syncthing.net/target/bin# syncthing -upgrade-check

-ash: syncthing: command not found


root@Synology:/var/packages/syncthing.net/target/bin# ./syncthing -upgrade-check

15:17:41 WARNING: Upgrade: upgrade unsupported

What shell are you using? The commands provided might only work on bash, and I am seeing -ash in your errors.

If you want to run a binary or script that’s inside your current directory, you must prefix it with ./

So if your current directory is /var/packages/syncthing.net/target/bin and you want to execute the syncthing binary in that directory, you have to use ./syncthing

Without this you’ll get the “command not found” error.

It seems, this parameter doesnt work, with of without the prefix.

What happens when you use the command? When you’re not providing specific details it’s difficult to help. Since there has been confusion, perhaps it would be best if you could copy and paste the exact command you use and what appears to happen.

Also keep in mind that -reset-database will not output anything, whether it works correctly or not, which is perhaps not ideal. To verify that the reset was successful, look in the config folder and you should find that the index-v...db folder is gone.

Thanks so much!
All my post in this topic have been written under the false assumption that resetting the database will also start Syncthing. Thanks for pointing out that it will just exit silently. I propose to change that: https://github.com/syncthing/syncthing/pull/6364

@Andy Sorry for the confusion. What you need to do (and the first part you have already done) is run two commands:

The first will not give any output and that’s ok:
/var/packages/syncthing/target/bin/syncthing -reset-database

The second then will (hopefully):
STTRACE=db /var/packages/syncthing/target/bin/syncthing 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

1 Like

No problem, its nice to work with you.

In this moment I´m running on two servers “./syncthing -reset-deltas”. This parameter also is running and I post the result.

After that I try your new commands from today.

That is clear and was considered, please follow our tests.

Understood. If you follow the post no. 18 and the follow, I have done.

That was clear and our tests was related to that. Please read the posts 18 and follow.

After my current command I try the reset and check, if the folder

/var/packages/syncthing/target/var/index-v0.14.0.db/

is deleted.

After using above, the folder from my last post, or that content was not deleted. Today I got as result as follow:

root@Synology:/# STTRACE=db /var/packages/syncthing/target/bin/syncthing 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

[start] 2020/02/26 09:37:48.017304 main.go:548: INFO: syncthing v1.4.0-rc.7 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 16:49:23 UTC

[start] 2020/02/26 09:37:48.039049 main.go:579: WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)

[monitor] 2020/02/26 09:37:48.041495 monitor.go:191: INFO: Syncthing exited: exit status 1

[start] 2020/02/26 09:37:49.094424 main.go:548: INFO: syncthing v1.4.0-rc.7 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 16:49:23 UTC

[start] 2020/02/26 09:37:49.117712 main.go:579: WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)

[monitor] 2020/02/26 09:37:49.120241 monitor.go:191: INFO: Syncthing exited: exit status 1

[start] 2020/02/26 09:37:50.168082 main.go:548: INFO: syncthing v1.4.0-rc.7 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 16:49:23 UTC

[start] 2020/02/26 09:37:50.191782 main.go:579: WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)

[monitor] 2020/02/26 09:37:50.193924 monitor.go:191: INFO: Syncthing exited: exit status 1

[start] 2020/02/26 09:37:51.245584 main.go:548: INFO: syncthing v1.4.0-rc.7 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 16:49:23 UTC

[start] 2020/02/26 09:37:51.269637 main.go:579: WARNING: Error opening database: resource temporarily unavailable (is another instance of Syncthing running?)

[monitor] 2020/02/26 09:37:51.271647 monitor.go:191: INFO: Syncthing exited: exit status 1

[monitor] 2020/02/26 09:37:52.273260 monitor.go:97: WARNING: 4 restarts in 4.30698446s; not retrying further

root@Synology:/#

This was also the content of the log file:

/volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

Is another instance of Syncthing running?

Yes, I had two installations, the SynoComm. and Kastelo, but Kastelo is paused. Maybe I deinstall the Kastelo installation.

No need to deinstall anything. Just make sure all Syncthing instances are stopped/shut-down/… before starting another one.

I stop the Kastelo service, also a reboot of server was needed. Now SynoComm package runs alone. I run


root@Synology:~# STTRACE=db /var/packages/syncthing/target/bin/syncthing 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

[start] 2020/02/26 10:19:16.917695 main.go:548: INFO: syncthing v1.4.0-rc.7 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 16:49:23 UTC

[start] 2020/02/26 10:19:17.978864 main.go:621: INFO: Automatic upgrade is always enabled for candidate releases.

[FBDWL] 2020/02/26 10:19:17.979177 syncthing.go:151: INFO: My ID: FBDWLxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[FBDWL] 2020/02/26 10:19:19.004630 sha256.go:87: INFO: Single thread SHA256 performance is 90 MB/s using minio/sha256-simd (66 MB/s using crypto/sha256).

[FBDWL] 2020/02/26 10:19:20.028751 syncthing.go:183: INFO: Hashing performance is 79.84 MB/s

[FBDWL] 2020/02/26 10:19:20.029012 model.go:273: INFO: Starting deadlock detector with 20m0s timeout

[FBDWL] 2020/02/26 10:19:20.029521 limiter.go:165: INFO: Overall send rate is unlimited, receive rate is unlimited

[FBDWL] 2020/02/26 10:19:20.030740 syncthing.go:271: INFO: Using discovery server https://discovery.syncthing.net /v2/?noannounce&id=LYXKCxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[FBDWL] 2020/02/26 10:19:20.030886 syncthing.go:271: INFO: Using discovery server https://discovery-v4.syncthing.net/v2/?nolookup&id=LYXKCxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[FBDWL] 2020/02/26 10:19:20.030956 syncthing.go:271: INFO: Using discovery server https://discovery-v6.syncthing.net/v2/?nolookup&id=LYXKCxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[FBDWL] 2020/02/26 10:19:20.031200 syncthing.go:305: INFO: Anonymous usage reporting is always enabled for candidate releases.

[FBDWL] 2020/02/26 10:19:20.031909 tcp_listen.go:55: INFO: Listen (BEP/tcp): listen tcp 0.0.0.0:22000: bind: address already in use

[FBDWL] 2020/02/26 10:19:20.032080 service.go:139: INFO: c.S.listenerSupervisor: Failed service ‘tcp://0.0.0.0:22000’ (1.000000 failures of 2.000000), restarting: true, error: “{tcp://0.0.0.0:22000 tcp://0.0.0.0:22000} returned unexpectedly”, stacktrace: [unknown stack trace]

[FBDWL] 2020/02/26 10:19:20.032220 tcp_listen.go:55: INFO: Listen (BEP/tcp): listen tcp 0.0.0.0:22000: bind: address already in use

[FBDWL] 2020/02/26 10:19:20.032267 service.go:139: INFO: c.S.listenerSupervisor: Failed service ‘tcp://0.0.0.0:22000’ (1.999995 failures of 2.000000), restarting: true, error: “{tcp://0.0.0.0:22000 tcp://0.0.0.0:22000} returned unexpectedly”, stacktrace: [unknown stack trace]

[FBDWL] 2020/02/26 10:19:20.032340 tcp_listen.go:55: INFO: Listen (BEP/tcp): listen tcp 0.0.0.0:22000: bind: address already in use

[FBDWL] 2020/02/26 10:19:20.032367 service.go:165: INFO: Entering the backoff state.

[FBDWL] 2020/02/26 10:19:20.032425 service.go:139: INFO: c.S.listenerSupervisor: Failed service ‘tcp://0.0.0.0:22000’ (2.999990 failures of 2.000000), restarting: false, error: “{tcp://0.0.0.0:22000 tcp://0.0.0.0:22000} returned unexpectedly”, stacktrace: [unknown stack trace]

[FBDWL] 2020/02/26 10:19:20.032554 relay_listen.go:62: INFO: Relay listener (dynamic+https://relays.syncthing.net/endpoint) starting

[FBDWL] 2020/02/26 10:19:20.033308 quic_listen.go:86: INFO: Listen (BEP/quic): listen udp 0.0.0.0:22000: bind: address already in use

[FBDWL] 2020/02/26 10:19:20.033373 service.go:165: INFO: Entering the backoff state.

[FBDWL] 2020/02/26 10:19:20.033417 service.go:139: INFO: c.S.listenerSupervisor: Failed service ‘quic://0.0.0.0:22000’ (3.999920 failures of 2.000000), restarting: false, error: “{quic://0.0.0.0:22000 quic://0.0.0.0:22000} returned unexpectedly”, stacktrace: [unknown stack trace]

[FBDWL] 2020/02/26 10:19:20.073173 model.go:371: INFO: Ready to synchronize “Default Folder” (default) (sendreceive)

[FBDWL] 2020/02/26 10:19:20.074836 set.go:303: DEBUG: default WithPrefixedHaveTruncated(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4, “”)

[FBDWL] 2020/02/26 10:19:20.075310 folder.go:593: INFO: Completed initial scan of sendreceive folder “Default Folder” (default)

[FBDWL] 2020/02/26 10:19:20.075589 set.go:266: DEBUG: default WithNeed(7777777-777777N-7777777-777777N-7777777-777777N-7777777-77777Q4)

[FBDWL] 2020/02/26 10:19:20.136138 api.go:360: INFO: GUI and API listening on 127.0.0.1:54347

[FBDWL] 2020/02/26 10:19:20.136398 api.go:361: INFO: Access the GUI via the following URL: http://127.0.0.1:54347/

[FBDWL] 2020/02/26 10:19:20.136671 syncthing.go:332: INFO: My name is “Synology”

[FBDWL] 2020/02/26 10:19:20.136713 syncthing.go:340: WARNING: Syncthing should not run as a privileged or system user. Please consider using a normal user account.

[FBDWL] 2020/02/26 10:19:46.736518 static.go:68: INFO: Joined relay relay://51.158.96.181:22067

root@Synology:~#

It seems you are tripping over the fact you have two packages. I suggest you get rid of one.

If needed, I deinstall the Kastelo installation, because is only for testing. Is the above feedback not plausible so that this becomes necessary?

Additionally I deinstall the Kastelo version. I try now

root@Synology:/var/packages/syncthing/target/bin# STTRACE=db /var/packages/syncthing/target/bin/syncthing -reset-database 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

root@Synology:/var/packages/syncthing/target/bin#

and needs 3-4 seconds. The folder

/var/packages/syncthing/target/var/index-v0.14.0.db/

was not empty and the log file

/volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

is empty, 0kb

If I try

root@Synology:/var/packages/syncthing/target/bin# STTRACE=db syncthing -reset-database 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

-ash: syncthing: command not found


root@Synology:/var/packages/syncthing/target/bin# STTRACE=db ./syncthing -reset-database 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

root@Synology:/var/packages/syncthing/target/bin#

Second line is coming in max. 1 second. Same as yesterday

If I use

root@Synology:/var/packages/syncthing/target/bin# STTRACE=db ./syncthing 2>&1 | tee /volume1/PublicSharings/SyncthingExchange/Syncthing_log_Synology_DS1815.log

it means without “-reset-database” the result is as above