Issue running after update to 15.2

Running the new cloned from on 7/17 (which has been updated to support 15.2) is generating the following error:

[root@vul06 storj_earnings]# python /mnt/storj/data/
ERROR SQLite3: Error: malformed database schema (idx_pieceinfo__expiration) - ne                                                                                                                  
ar "WHERE": syntax error

As far as I can tell, I have no issues running my node that this point.

Logs after the last restart are:

2019-07-17T14:15:49.420Z        INFO    Got a signal from the OS: "terminated"
2019-07-17T14:15:51.324Z        INFO    Configuration loaded from: /app/config/config.yaml
2019-07-17T14:15:51.338Z        INFO    Operator email: Scrubbed
2019-07-17T14:15:51.338Z        INFO    Operator wallet: 0xScrubbed
2019-07-17T14:15:51.544Z        INFO    running on version v0.15.2
2019-07-17T14:15:51.811Z        INFO    db.migration    Latest Version  {"version": 13}
2019-07-17T14:15:51.812Z        INFO    vouchers        Checking vouchers
2019-07-17T14:15:51.814Z        INFO    Node 
1Fhm5o5Ky2cmV2DwQNYqhxgei3d6ZhDrpoNtUhGhZmvLBdJTFk started
2019-07-17T14:15:51.814Z        INFO    Public server started on [::]:28967
2019-07-17T14:15:51.814Z        INFO    Private server started on
2019-07-17T14:15:51.836Z        INFO    running on version v0.15.2
2019-07-17T14:15:52.140Z        INFO    piecestore:monitor      Remaining Bandwidth     {"bytes": 
2019-07-17T14:30:51.989Z        INFO    running on version v0.15.2

@rootdet mentioned the same issue to me. He also found that running an integrity check on the db throws the same error suggesting it’s an issue with the db integrity, not the script. But please let me know if others are having issues. The script worked fine for me on both windows and linux environments. But I only have my own node’s info.db to test on.

It is an interresting one. @Alexey had me remove my container, delete info.db, repull from github and start storagenode again. Integrity check on info.db while stopped seems to still show that error, which also appears in the earning script, and I linked it to a some INDEX creations at the bottom of the sql, but not sure why it keeps replicating to even a fresh info.db that gets created.

Will let you know if they get it sorted for me and the potential fix.

1 Like

Note: If you start over with an empty info.db it will have lost the historic bandwidth usage and thus the bandwidth from prior to today will no longer be used during calculation. In addition to that, anyone reading this at a later date, please do not remove your info.db as this is likely only an option now because of the network wipe and nodes that have data need their info.db as well.

@itspecific Cant confirm. For me is worked as I expect.

root@node:/home/sources/storj# python "/home/StorjStore/storage"

July 2019 (Version: 5.0.0)			[snapshot: 2019-07-17 15:27:07Z]
			Type		Disk	   Bandwidth		Payout
Upload			Ingress			     1.70 TB	    -not paid-
Upload Repair		Ingress			     9.82 GB	    -not paid-

The only other potentially relevant thing I did was restart my node after the migration completed. Just throwing it out there in case it is relevant.

You should use more fresh version of sqlite3
we uses v3.25.2

Thanks for that info!
I can confirm 3.10.2 works for me on linux.
3.28.0 works for me on windows.

Can’t update the linux version as it is the version that comes with DSM on Synology. But it looks like I don’t need to.

To check:

sqlite3 --version

So I’m trying to run v0.15.3, I moved to a new IP at the same datacenter, when I run the script now I get this error:

root@localhost:~# python3 /ext/store
Traceback (most recent call last):
  File "", line 127, in <module>
    put_total = put_total + int(data[1])
IndexError: list index out of range


root@localhost:~# sqlite3 --version
3.22.0 2018-01-22 18:45:57 0c55d179733b46d8d0ba4d88e01a25e10677046ee3da1d5b1581e86726f2alt1

Updating my sqlite3 to the latest version resolved the issue. Now works as expected.

Currently running
3.29.0 2019-07-10 17:32:03 fc82b73eaac8b36950e527f12c4b5dc1e147e6f4ad2217ae43ad82882a88bfa6

It was (bundled with CentOS7)
3.7.17 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668

Thanks for the help folks!

@subwolf make sure you are using the latest version of the script. It should give more descriptive errors. You should be using v5.0.0. li k is in the top post.

@rootdet @itspecific I’ve updated the script to version 5.2.0 which removes the external dependency for SQLite3 by using internal Python packages. As long as you have Python 2.5 or higher it should work now without SQLite3 installed as well.