Skip to main content
Welcome to DATA Foundation node troubleshooting! This section covers common problems and solutions when running DATA Foundation nodes.

​
Node Setup

See the system specs
~700
Yes, it’s EVM-compatible. The DATA Foundation’s execution client is a fork of Geth with our custom precompiles, which enhance the IP graph’s performance while maintaining strict EVM compatibility. Other Ethereum execution clients, such as RETH and Erigon, can be supported later.
Our consensus mechanism is CometBFT
Batch RPCs are supported - for Geth there is a 1K limit and on the consensus side there is 10 request limit
Yes, WS is enabled on the execution client, and is recommended for subscription use-cases. It is open on port 8546
Please see Geth’s latest JSON-RPC documentation for a full comprehensive list here. In the future, we may add more.
We recommend employing standard in-memory caching with a 1-10 min TTL based on the RPC method
Use eth_syncing RPC call on the execution client to check if the node is sync and eth_blockNumber for getting the latest block
eth_call / eth_getLogs / eth_getBlockByNumber
We are still running latency tests to get a sense of response times.
No, not at the moment.
Not yet, but we are working on it.

​
Common Issues

Error:
Solution:
  1. Save your validator state:
🚧 Be very careful with this file, especially if your validator is already signing blocks.
  • Check your the database backend type, your node must support the same as you are using the snapshot:
Default is app-db-backend = "goleveldb". The fallback is the db_backend value set in CometBFT’s config.toml.
Problem: Need to adjust gas fees on RPC nodeSolution: Add the --rpc.txfee flag to your geth startup command:
Error:
Solution:
  • If the node is synchronized, you can ignore this error. Your client may be a little behind.
  • If the node stops, you should restart the services.
An error occurs when starting the cosmovisor:
Solution:
  • You must ensure that the installed cosmovisor version must be at least v1.7.0.
  • Then check your info file (edit version v0.13.0 in your case):
If you don`t have create new one:
Find out more about automatic updates with cosmovisor here.
Error:
Solution:
  • It looks like port 8551 stopping, the background process running iptables blocking ip and port and access posix.
  • For solution try uninstall ufw posix and iptables:
Error:
Solution:
  • The validator has been double signed. It is currently not possible to restore the validator after it has been double signed.
  • To avoid such situations, see this post on how to correctly migrate a validator to another machine.
Error:
Solution:
  • You missed flag --moniker.
  • The command to create a new validator should look like this:
See more options here.
Error:
Solution:
  • It looks like your node is down. To get started, check the current versions of the binaries here.
  • If you have up-to-date binary - try updating peers, this usually happens when a node loses p2p communication:
Error:
Solution:
  • Looks like you have a problem with your priv_validator_state of validator.
    🚧 Be very careful with this file, especially if your validator is already signing blocks.
  • You can make a copy of your state with a command:
Check your validator state:
  • If you get this error, you can reset your state (🚧 ONLY IF YOUR VALIDATOR HAS NOT YET SIGNET BLOCKS).
  • Stop node.
  • Start node.
Error:
Solution:
  • It looks like a misconfiguration. You must try to remove the --home flag from the startup command.
  • Your systemd to run might look like this:
Error:
Solution:
  • You have problems with the state of validator or a corrupted database.
  • Try using a snapshot.
    🚧 Be very careful with this file, especially if your validator is already signing blocks.
  • We have described how to reset your state here.

​
Failed to reconnect to peer

Error:
Solution:
  • If the node is synchronized and not far behind, you can ignore this error.
  • If the node is lagging or has stopped completely, try updating peers, this usually happens when a node loses p2p communication:
Warn:
Solution:
  • It just means that story-geth is syncing, you can ignore this warn.
  • However, if it takes a long time, we recommend that you stop the processes one at a time and start them again later in the following order:
Error:
Solution:
  • Looks like you missed an update.
  • To get started, check the current versions of the binaries here.
Error:
Solution:
  • This means that you have already initialized the node.
  • $HOME/.story/story directory created, and there are files in it. Delete it, or try with it.
Error:
Solution:
  • It appears that your node is using incorrect versions.
  • Check the current versions of the binaries here.
  • And most likely you need to perform a rollback binary to current versions.
Error:
Solution:
  • Looks like an AppHash issue.
  • To get started, upgrade to the current versions of the binaries here.
  • If your versions are newer than the current ones, perform a rollback.
Error:
Solution:
  • It seems your node can’t get jwtsecret.
  • Check your WorkingDirectory in your geth-service , by default WorkingDirectory=$HOME/.story/geth.
  • Check all paths, you can get your jwtsecretwith command (for odyssey network):
Error:
Solution:
  • If the node is synchronized and not far behind, you can ignore this error.
  • If the node is lagging or has stopped completely, try updating seeds/peers, it usually happens when a node loses p2p communication (we recommend that you stop the node and delete the addrbook).
Warn:
Solution:
  • Everything is fine, it just means that story-geth is syncing, which takes some time.
  • If the node is not far behind, you can ignore this warning.

​
Dial tcp 127.0.0.1:9090

Warn:
Solution:
  • The logs show a connection failure on port 9090.
  • Check the listening ports:
  • If other node uses 9090, then modify it to another.
  • Normally, this WARNING should not affect the performance of your node.
Error:
Solution:
  • Wrong AppHash type logs means the story node version you are using is wrong.
  • Upgrade to the current versions of the binaries here.
  • If your versions are newer than the current ones, perform a rollback.
Error:
Solution:
  • If the node is synchronized and not far behind, you can ignore this error.
  • If the node is lagging or has stopped completely, try updating peers, this usually happens when a node loses p2p communication:
Error:
Solution:
  • Looks like a problem with your node moniker.
  • Be sure to use "" when executing init:
  • Go to config, find the moniker and put it inside "" only:
Error:
Solution:
  • The logs report a connection failure on port 26656.
  • Check the listening ports:
  • If another node is using 26656, change it to another and keep the default 26656 for story in the P2P configuration options in config:
Warn:
Solution:
  • This error indicates that the network has stopped.
Warn:
Solution:
  • It looks like port 8551 stopping, the background process running iptables blocking ip and port and access posix.
  • For solution try uninstall ufw posix and iptables: