On my Windows Devices the update to v1.4.0-rc.6 was okay. On my 1 Synology server the update is still running because of database upgrade.
It means there is a further modification at database?
I got a set of files:
panic-20200222-111241.reported.log panic-20200222-111357.reported.log panic-20200222-111514.reported.log panic-20200222-111636.reported.log panic-20200222-111748.reported.log panic-20200222-111854.reported.log panic-20200222-112003.reported.log panic-20200222-112055.reported.log panic-20200222-112147.reported.log panic-20200222-112238.reported.log panic-20200222-112333.reported.log panic-20200222-112425.reported.log panic-20200222-112521.reported.log panic-20200222-112615.reported.log panic-20200222-112708.reported.log panic-20200222-112759.reported.log panic-20200222-112848.reported.log panic-20200222-112938.reported.log panic-20200222-113032.reported.log panic-20200222-113124.reported.log panic-20200222-113217.reported.log panic-20200222-113309.reported.log panic-20200222-113359.reported.log panic-20200222-113448.reported.log panic-20200222-113539.reported.log panic-20200222-113629.reported.log panic-20200222-113720.reported.log panic-20200222-113810.reported.log panic-20200222-113900.reported.log panic-20200222-113950.reported.log panic-20200222-114045.reported.log panic-20200222-114138.reported.log panic-20200222-114231.reported.log panic-20200222-114325.reported.log panic-20200222-114423.reported.log
with beginning:
[start] 11:45:19 INFO: syncthing v1.4.0-rc.6 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 08:37:21 UTC [start] 11:45:19 INFO: Using large-database tuning [start] 11:45:21 INFO: Automatic upgrade is always enabled for candidate releases. [FSBSS] 11:45:21 INFO: My ID: xxxxxxxxxxxxxxxxx [FSBSS] 11:45:22 INFO: Single thread SHA256 performance is 89 MB/s using minio/sha256-simd (64 MB/s using crypto/sha256). [FSBSS] 11:45:23 INFO: Hashing performance is 76.91 MB/s [FSBSS] 11:45:23 INFO: Migrating database to schema version 9… [FSBSS] 11:46:15 WARNING: Blocks is nil, but BlocksHash is not for file File{Name:“von CDs und DVDs/Shrek.der.Dritte.TS.LD.RSVCD.by.Sbw-Crew.mpg”, Sequence:5533, Permissions:0777, ModTime:2007-08-07 03:42:23 +0200 CEST, Version:{[{FSBSS4H 1}]}, Length:840381640, Deleted:false, Invalid:false, LocalFlags:0x0, NoPermissions:false, BlockSize:524288, Blocks:[]} … Panic at 2020-02-22T11:46:15+01:00 panic: Blocks is nil, but BlocksHash is not
Any ideas about?
I had one too, but it looked like it was when rc5 was being closed to upgrade to rc6
In the meantime I have 105 of such logs. What is the meaning with
“[start] 12:37:36 INFO: Using large-database tuning”
I have in each file?
Understood. But the meaning for me that regarding of each current file
[start] 12:57:04 INFO: Using large-database tuning
[FSBSS] 12:57:07 INFO: Migrating database to schema version 9…
such processes starts from beginning and it seems with no ending.
Its when Syncthing starts up it appears. Mines the same, it’s just for reference.
[start] 09:39:02 INFO: syncthing v1.4.0-rc.6 “Fermium Flea” (go1.13.8 windows-amd64) teamcity@build.syncthing.net 2020-02-22 08:37:21 UTC
[start] 09:39:02 INFO: Using large-database tuning
[start] 09:39:03 INFO: Automatic upgrade is always enabled for candidate releases.
[RTF25] 09:39:03 INFO: My ID: xxxxxx
[RTF25] 09:39:04 INFO: Single thread SHA256 performance is 340 MB/s using crypto/sha256 (321 MB/s using minio/sha256-simd).
[RTF25] 09:39:05 INFO: Hashing performance is 258.06 MB/s
[RTF25] 09:39:05 INFO: Migrating database to schema version 9…
That probably means that it still works also for you. Can you still reach the GUI? Not me and for 90 minutes now. It’s just a little worrying.
Now actual file - all time the same:
[start] 13:27:27 INFO: syncthing v1.4.0-rc.6 “Fermium Flea” (go1.13.8 linux-amd64) teamcity@build.syncthing.net 2020-02-22 08:37:21 UTC
[start] 13:27:27 INFO: Using large-database tuning
[start] 13:27:27 INFO: Automatic upgrade is always enabled for candidate releases.
[FSBSS] 13:27:27 INFO: My ID: xxxxxxxxxx
[FSBSS] 13:27:28 INFO: Single thread SHA256 performance is 92 MB/s using minio/sha256-simd (68 MB/s using crypto/sha256).
[FSBSS] 13:27:29 INFO: Hashing performance is 80.42 MB/s
[FSBSS] 13:27:29 INFO: Migrating database to schema version 9…
[FSBSS] 13:28:19 WARNING: Blocks is nil, but BlocksHash is not for file File{Name:“von CDs und DVDs/Shrek.der.Dritte.TS.LD.RSVCD.by.Sbw-Crew.mpg”, Sequence:5533, Permissions:0777, ModTime:2007-08-07 03:42:23 +0200 CEST, Version:{[{FSBSS4H 1}]}, Length:840381640, Deleted:false, Invalid:false, LocalFlags:0x0, NoPermissions:false, BlockSize:524288, Blocks:[]} …
open resource monitor and have a look at the files and disk activity. It is possible the db is still upgrading, however mine was near instant going from rc5-6. However when I went from 1.3.4 to 1.4 it took around 30 minutes on an ssd
ah, you have linux. is there any way to see whats happening?
Surely it depend on all the sizes and perfomance. By me it tooks round 20 minutes. What is going on my installation for now is unusual and not normal for me.
Is GUI reachable?
If you look back on this thread, I posted screen shots of my gui (the darker pictures.) Is yours doing the same, or is it blank like the ones where the webpage says ‘the site can’t be reached’?
i’m wondering if you are having the same issue I have been having.
No, it is not the same message. It’s like Syncthing didn’t start. The website remains empty with the feedback of the “Error: Connection failed”.
What is the status with you? Like in this dark picture or like me?
I made a reboot of my server, but Syncthing goe ahead with the writing of logs, currently
panic-20200222-140107.reported.log
with content of line 2 and 3:
[start] 14:00:18 INFO: Using large-database tuning
[start] 14:00:19 INFO: Automatic upgrade is always enabled for candidate releases.
Has nothing to do with db tuning, it’s a bug I introduced in rc6 (sorry): https://github.com/syncthing/syncthing/issues/6353
1 Like
Understood. In which way I can stop the progress and step back to rc.5 on my Synology server? Why my Window computers are not affected? Two computers updated to rc.6 and runs without problems.
Stop of the service and renaming of “syncthing” (rc.6) in “syncthing.new” and “syncthing.old” (rc.5) in “syncthing” was the solution. After starting the service Syncthing, the v1.4.0-rc.5 on my Synology server is running again, GUI is reachable as before.
Many thanks for your good work. Server and clients are running in a usual and proper condition, all with v1.4.0-rc.7.
So I’m getting this issue with SyncTrayzor running on a Windows PC with the log below:
[JWNFO] 17:21:43 INFO: Automatic upgrade (current “v1.4.0-rc.6” < latest “v1.4.0-rc.10”) [JWNFO] 17:21:44 INFO: Migrating database to schema version 9… [JWNFO] 17:21:44 WARNING: Blocks is nil, but BlocksHash is not for file File{Name:".picasa.ini", Sequence:18606, Permissions:0644, ModTime:2014-10-31 07:19:40 +0000 GMT, Version:{[{JWNFO4C 1}]}, Length:26, Deleted:false, Invalid:false, LocalFlags:0x0, NoPermissions:false, BlockSize:131072, Blocks:[]} panic: Blocks is nil, but BlocksHash is not [monitor] 17:21:44 WARNING: Panic detected, writing to “C:\Users\paul\AppData\Local\Syncthing\panic-20200304-172144.log” [start] 17:21:45 INFO: syncthing v1.4.0-rc.6 “Fermium Flea” (go1.13.8 windows-amd64) teamcity@build.syncthing.net 2020-02-22 08:37:21 UTC [start] 17:21:45 INFO: Using large-database tuning [start] 17:21:45 INFO: Automatic upgrade is always enabled for candidate releases. [JWNFO] 17:21:45 INFO: Automatic upgrade (current “v1.4.0-rc.6” < latest “v1.4.0-rc.10”) [JWNFO] 17:21:46 INFO: Single thread SHA256 performance is 437 MB/s using minio/sha256-simd (377 MB/s using crypto/sha256). [JWNFO] 17:21:46 INFO: Migrating database to schema version 9… [JWNFO] 17:21:46 WARNING: Blocks is nil, but BlocksHash is not for file File{Name:".picasa.ini", Sequence:18606, Permissions:0644, ModTime:2014-10-31 07:19:40 +0000 GMT, Version:{[{JWNFO4C 1}]}, Length:26, Deleted:false, Invalid:false, LocalFlags:0x0, NoPermissions:false, BlockSize:131072, Blocks:[]} panic: Blocks is nil, but BlocksHash is not [monitor] 17:21:46 INFO: Reporting crash found in panic-20200304-172146.log (report ID e6f2529b) …
How do I fix it?