Migration to schema 15 failed "checking globals: unexpected EOF"

Support
1

I’ve upgraded to v1.12.0 and have one box which is reporting failure after trying to migrate to schema 15:

[start] 18:30:26 INFO: syncthing v1.12.0 "Fermium Flea" (go1.15.5 netbsd-amd64) abs@iris.absd.org 2020-12-03 17:56:33 UTC [noupgrade]
[start] 18:30:26 INFO: Using large-database tuning
[V5HIY] 18:30:26 INFO: My ID: xxxxxx
[V5HIY] 18:30:27 INFO: Single thread SHA256 performance is 57 MB/s using minio/sha256-simd (51 MB/s using crypto/sha256).
[V5HIY] 18:30:27 INFO: Hashing performance is 66.85 MB/s
[V5HIY] 18:30:27 INFO: Running database migration 14...
[V5HIY] 18:31:40 INFO: Running database migration 15...
[V5HIY] 18:30:24 WARNING: Database schema: failed to do migration 15: checking globals: unexpected EOF
[V5HIY] 18:30:24 INFO: Exiting

The host was running as a receive only endpoint for around 12TB of data, so if its possible to clear and restart it such that it would pickup existing files and not need to retransfer that could be a recovery option?

Thanks

David

2

No idea how that happened, especially connected to a migration - probably just happenstance. Check the health of the device where the database is stored on.

Anyways when you reset the database (rename/remove the index-v0.14.0.db dir) it will rescan all files and then exchange metadata with all devices - if nothing changed since the last scan before the upgrade, no data will be retransfered.

3

There were… a few panic reported log files (it seemed to sit in an exit/restart & retry loop - I wonder if that should have some form of counter and limit?

% find . -name panic-\*.reported.log | wc -l
   20233
% find . -name .syncthing.tmp\* | wc -l      
    3705

index-v0.14.0.db was around 8.5GB, have moved to one side in case it may be of diagnostic interest & restarted. Will go have a cup of tea (potentially including picking and drying the leaves first) while it reindexes :slight_smile:

Thanks

David

2 Likes
4

Yeah, we get a few of these hammering our sentry server xD

Our monitor script is backing off (stopping to restart) if it restarts 4 times in a minute. Either some other daemon controller doesn’t do that and keeps restarting or a few setups hit that sweet spot where they crash fairly consistently and often, but never 4 times within a minute.

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.