1

I have set up a public node and a private baker. See this question for details.

Both nodes trust each others identity, and the private node connects to the public one with --peer (or ./tezos-admin-client connect address A.A.A.A when I force it).

But the connection only lasts about a minute, and the private baker node reports:

tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline: Unexpected error (validator):
tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline: Error, dumping error stack:
tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline:   Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:3 timed out
tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline:   Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:2 timed out
tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline:   Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:1 timed out
tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline:   Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:0 timed out
tezos-node[7756]: Apr 17 13:38:24 - node.validator.bootstrap_pipeline:
tezos-node[7756]: Apr 17 13:38:24 - validator.peer(4): Worker crashed [NetXdQprcVkpa:idtU5hsGUt7G]:
tezos-node[7756]: Apr 17 13:38:24 - validator.peer(4): Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:0 timed out
tezos-node[7756]: Apr 17 13:38:24 - validator.peer(4): Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:1 timed out
tezos-node[7756]: Apr 17 13:38:24 - validator.peer(4): Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:2 timed out
tezos-node[7756]: Apr 17 13:38:24 - validator.peer(4): Fetch of operations BM7ecfiPecW1tpw4z6xfrbqjBnf5JjAZEWU9jcSqhZ54jfYzoMi:3 timed out

I also just updated to newest tezos version from gitlab today (git rev-parse HEAD returns d272059bf474018d0c39f5a6e60634a95f0c44aa).

What can I do to keep my private node connected to my public node?

6

The issue is not related to the fact that your node is private.

If you wait a while the not bootstrapped (here the "private") node will reconnect itself to its public nodes, resync for a while... until the problem may show up again, and it restarts for an other loop ... until the full sync of the node!

The problem is "the suboptimal way by which the received blocks are written on the disk for now": In the bootstrapping phase, a node receives and validates tons of blocks very quickly. When the "hard drive" performance does not follow (it is not the hard drive fault, it is the "incorrect" use of lmdb), it sometime takes more than a minute for one of the block in the sea of blocks to be validated. In this case, the node thinks that it is the fault of the peer it asks the block to that didn't answer fast enough and kick it whereas it is its own fault...

Improving the storage of blocks (for size and efficiency!) is a very active work in progress.

| improve this answer | |
  • 1
    Auch, that's quite near impossible for newcomers to guess. But thank you very much for the info. – Svante Apr 17 '19 at 13:34
  • So a possible solution could be bootstrapping the node in "public" mode, and once it's synced, setting it private? Or what's your recommendation here? – raulmarcosl Oct 12 '19 at 16:38
  • 1
    New improved storage that fixes this behavior is just around the corner. My recommendation is "wait for a week for the release to happen and forget about this problem" :-) – Pierre Boutillier Oct 14 '19 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.