Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node startup failed #2405

Closed
astrid19981112 opened this issue Apr 18, 2024 · 12 comments
Closed

Node startup failed #2405

astrid19981112 opened this issue Apr 18, 2024 · 12 comments
Assignees

Comments

@astrid19981112
Copy link

Run command
/data/geth_linux --config ./config.toml --datadir ./geth/ --cache 8000 --rpc.allow-unprotected-txs --tries-verify-mode none --history.transactions=0 --syncmode =full --tries-verify-mode=local --pruneancient --db.engine=pebble --state.scheme=path

running version
geth_linux.1 version 1.3.13-bae7e6b5-20240401

Running error
cat bsc.log
t=2024-04-18T15:05:01+0800 lvl=info msg="Use CLI state scheme" CLI=path
t=2024-04-18T15:05:01+0800 lvl=info msg="Set global gas cap" cap=50,000,000
t=2024-04-18T15:05:01+0800 lvl=info msg="Initializing the KZG library" backend=gokzg
t=2024-04-18T15:05:01+0800 lvl=info msg="Using pebble as the backing database"
t=2024-04-18T15:05:01+0800 lvl=info msg="Allocated cache and file handles" database=/data/geth/geth/chaindata cache="3.12 GiB" handles=32767 "memory table"=" 800.00 MiB"
t=2024-04-18T15:05:02+0800 lvl=info msg="Read ancientdb item counts" items=0
t=2024-04-18T15:05:02+0800 lvl=info msg="Opened ancientdb with nodata mode" database=/data/geth/geth/chaindata/ancient/chain frozen=35,456,035
t=2024-04-18T15:05:02+0800 lvl=info msg="State scheme set by user" scheme=path
t=2024-04-18T15:05:02+0800 lvl=info msg="Capped dirty cache size" provided="1.95 GiB" adjusted="256.00 MiB"
t=2024-04-18T15:05:02+0800 lvl=info msg="Clean cache size" provided="1.17 GiB"
t=2024-04-18T15:05:02+0800 lvl=info msg="Allocated trie memory caches" clean="1.17 GiB" dirty="256.00 MiB"
t=2024-04-18T15:05:02+0800 lvl=info msg="Unprotected transactions allowed"
t=2024-04-18T15:05:02+0800 lvl=info msg=Parlia chainConfig="{ChainID: 56 Homestead: 0 DAO: DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople : 0 Petersburg: 0 Istanbul: 0, Muir Glacier: 0, Ramanujan: 0, Niels: 0, MirrorSync: 5184000, Bruno: 13082000, Berlin: 31302048, YOLO v3: , CatalystBlock: , London: 31302048 , ArrowGlacier: , MergeFork:, Euler: 18907621, Gibbs: 23846001, Nano: 21962149, Moran: 22107423, Planck: 27281024, Luban: 29020050, Plato: 30720096, Hertz: 3130204 8, Hertzfix: 34140700, ShanghaiTime : 1705996800, KeplerTime: 1705996800, Engine: parlia}"
t=2024-04-18T15:05:02+0800 lvl=info msg="Initialising Ethereum protocol" network=56 dbversion=8
t=2024-04-18T15:05:02+0800 lvl=info msg="new async node buffer" limit="256.00 MiB" layers=0
t=2024-04-18T15:05:02+0800 lvl=info msg="Opened ancient database" database=/data/geth/geth/chaindata/ancient/state readonly=false frozen=0
t=2024-04-18T15:05:02+0800 lvl=crit msg="Failed to truncate extra state histories" err="out of range, tail: 0, head: 0, target: 37957483"

Failed to truncate extra state histories" err="out of range, tail: 0, head: 0, target: 37957483"

How do I need to operate it so that it can start normally?

@weiihann
Copy link
Contributor

Did you download a snapshot or sync from scratch?

@weiihann weiihann self-assigned this Apr 18, 2024
@astrid19981112
Copy link
Author

I want to know the reason for this. Do I need to resynchronize?

@weiihann
Copy link
Contributor

We need more context to solve the problem. Did you sync from a snapshot? Did you change any command line arguments before the current one?

@astrid19981112
Copy link
Author

Yes, I synchronized with the snapshot I used before, but I don’t remember which version it was.

Current startup command
/data/geth_linux --config ./config.toml --datadir ./geth/ --cache 8000 --rpc.allow-unprotected-txs --tries-verify-mode none --history.transactions=0 --syncmode =full --tries-verify-mode=local --pruneancient --db.engine=pebble --state.scheme=path

Previous startup command
/data/geth_linux--config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --txlookuplimit 0 --tries-verify-mode none

@astrid19981112
Copy link
Author

@weiihann
Copy link
Contributor

The issue is that previously you were running --tries-verify-mode none, which represents a fast node. Now you're running --tries-verify-mode local, which represents a full node. You can't convert fast node into a full node.

If you would like to run a full node, you need resync again from snapshot or from genesis.

If you don't mind continue running a fast node, you can just change --tries-verify-mode local back to --tries-verify-mode none.

Learn more here: https://docs.bnbchain.org/docs/BSC-separate-node/

@astrid19981112
Copy link
Author

That is, I received in the afternoon that our full node is out of sync, and git needs to be upgraded today (https://github.com/bnb-chain/bsc/releases/tag/v1.3.13)
Then I upgraded late. Do I need to resynchronize the snapshot at this time?
Thanks

@astrid19981112
Copy link
Author

Upgrade is late

@astrid19981112
Copy link
Author

Now I don't know if every time I force an update, I have to use snapshot synchronization before I can fully run the node.
And I sometimes, when forced to update, I will update my full node later than the forced update. Is there any way to repair my node, other than resynchronizing my full node with a new snapshot?
help me

@zzzckck
Copy link
Collaborator

zzzckck commented Apr 18, 2024

Now I don't know if every time I force an update, I have to use snapshot synchronization before I can fully run the node. And I sometimes, when forced to update, I will update my full node later than the forced update. Is there any way to repair my node, other than resynchronizing my full node with a new snapshot? help me

I think if you forget to update your node before the hardfork, your node should be stuck at the fork height. And it should recover automatically once your upgrade your node later.
If it is not, then I suppose there is a bug.

@rafaelsantana-mb
Copy link

Our node only was able to sync after update to v1.4.5 (pre-release) version.
Maybe this PR fixed the problem: #2359

@zzzckck
Copy link
Collaborator

zzzckck commented Apr 18, 2024

Our node only was able to sync after update to v1.4.5 (pre-release) version. Maybe this PR fixed the problem: #2359

got it, thx, we will make v1.4.5 as the official latest release.

@zzzckck zzzckck closed this as completed Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants