Docker node does not finish loading the blocks

I started a node for testnet with docker, but for some reason it is always loading more and more blocks, and it doesn’t finish, I have about 2 hours waiting.

main.config.json
{“VERSION”:“4.5.0”,“PERSISTED_NODE_ID”:“13f3b740767c6601”}
this is docker.yaml file

# This is an example configuration for running the testnet node

version: '3'

services:

  testnet-node:

    container_name: testnet-node

    image: concordium/testnet-node:latest

    pull_policy: always

    environment:

      # Environment specific configuration

      # The url where IPs of the bootstrap nodes can be found.

      - CONCORDIUM_NODE_CONNECTION_BOOTSTRAP_NODES=bootstrap.testnet.concordium.com:8888

      # Where the genesis is located

      - CONCORDIUM_NODE_CONSENSUS_GENESIS_DATA_FILE=/testnet-genesis.dat

      # The url of the catchup file. This speeds up the catchup process.

      - CONCORDIUM_NODE_CONSENSUS_DOWNLOAD_BLOCKS_FROM=https://catchup.testnet.concordium.com/blocks.idx

      # General node configuration Data and config directories (it's OK if they

      # are the same). This should match the volume mount below. If the location

      # of the mount inside the container is changed, then these should be

      # changed accordingly as well.

      - CONCORDIUM_NODE_DATA_DIR=/mnt/data

      - CONCORDIUM_NODE_CONFIG_DIR=/mnt/data

      # The port on which the node will listen for incoming connections. This is a

      # port inside the container. It is mapped to an external port by the port

      # mapping in the `ports` section below. If the internal and external ports

      # are going to be different then you should also set

      # `CONCORDIUM_NODE_EXTERNAL_PORT` variable to what the external port value is.

      - CONCORDIUM_NODE_LISTEN_PORT=8889

      # Desired number of nodes to be connected to.

      - CONCORDIUM_NODE_CONNECTION_DESIRED_NODES=5

      # Maximum number of __nodes__ the node will be connected to.

      - CONCORDIUM_NODE_CONNECTION_MAX_ALLOWED_NODES=10

      # Address of the GRPC server

      - CONCORDIUM_NODE_RPC_SERVER_ADDR=0.0.0.0

      # And its port

      - CONCORDIUM_NODE_RPC_SERVER_PORT=10001

      # Address of the V2 GRPC server

      - CONCORDIUM_NODE_GRPC2_LISTEN_PORT=20001

      # And its port

      - CONCORDIUM_NODE_GRPC2_LISTEN_ADDRESS=0.0.0.0

      # Maximum number of __connections__ the node can have. This can temporarily be more than

      # the number of peers when incoming connections are processed. This limit

      # ensures that there cannot be too many of those.

      - CONCORDIUM_NODE_CONNECTION_HARD_CONNECTION_LIMIT=20

      # Number of threads to use to process network events. This should be

      # adjusted based on the resources the node has (in combination with

      # `CONCORDIUM_NODE_BAKER_HASKELL_RTS_FLAGS`) below.

      - CONCORDIUM_NODE_CONNECTION_THREAD_POOL_SIZE=2

      # The bootstrapping interval in seconds. This makes the node contact the

      # specified bootstrappers at a given interval to discover new peers.

      - CONCORDIUM_NODE_CONNECTION_BOOTSTRAPPING_INTERVAL=1800

      # Haskell RTS flags to pass to consensus. `-N2` means to use two threads

      # for consensus operations. `-I0` disables the idle garbage collector

      # which reduces CPU load for non-baking nodes.

      - CONCORDIUM_NODE_BAKER_HASKELL_RTS_FLAGS=-N2,-I0

    entrypoint: ["/concordium-node"]

    # Exposed ports. The ports the node listens on inside the container (defined

    # by `CONCORDIUM_NODE_LISTEN_PORT` and `CONCORDIUM_NODE_RPC_SERVER_PORT`)

    # should match what is defined here. When running multiple nodes the

    # external ports should be changed so as not to conflict.

    # In the mapping below, the first port is the `host` port, and the second

    # port is the `container` port. When the `container` port is changed the

    # relevant environment variable listed above must be changed as well. For

    # example, changing `10001:10001` to `10001:13000` would mean that

    # `CONCORDIUM_NODE_RPC_SERVER_PORT` should be set to `13000`. Otherwise

    # the node's gRPC interface will not be available from the host.

    ports:

    - "8889:8889"

    - "10001:10001"

    - "20001:20001"

    volumes:

    # The node's database should be stored in a persistent volume so that it

    # survives container restart. In this case we map the **host** directory

    # /var/lib/concordium-testnet to be used as the node's database directory.

    - /var/lib/concordium-testnet:/mnt/data

  # The collector reports the state of the node to the network dashboard. A node

  # can run without reporting to the network dashboard. Remove this section if

  # that is desired.

  testnet-node-collector:

    container_name: testnet-node-collector

    image: concordium/testnet-node:latest

    pull_policy: always

    environment:

      # Settings that should be customized by the user.

      - CONCORDIUM_NODE_COLLECTOR_NODE_NAME=docker-test

      # Environment specific settings.

      - CONCORDIUM_NODE_COLLECTOR_URL=https://dashboard.testnet.concordium.com/nodes/post

      # Collection settings.

      # How often to collect the statistics from the node.

      - CONCORDIUM_NODE_COLLECTOR_COLLECT_INTERVAL=5000

      # The URL where the node can be reached. Note that this will use the

      # docker created network which maps `testnet-node` to the internal IP of

      # the `testnet-node`. If the name of the node service is changed from

      # `testnet-node` then the name here must also be changed.

      - CONCORDIUM_NODE_COLLECTOR_GRPC_HOST=http://testnet-node:10001

    entrypoint: ["/node-collector"]

hi osmany!
Logs will continue to show real-time synchronization and more and more new records will constantly appear that contain information about the current operation of the node and the blockchain. This is completely normal and works as it should. With each new finalized block in the chain (which appears approximately every 10-15 seconds), you will see new logs.

As I can see on the dashboard, your node has fully synced and continues to do so :slightly_smiling_face: As soon as you run your node for the first time, then the blockchain database starts to synchronize the chain and you could notice a huge number of logs, but once full synchronization is achieved, the appearance of logs will be, as I said above, with each new block.

1 Like

@osmany When the node starts up it needs to catch up with the head of the chain.

From the screenshot it looks like your node was almost caught up at that point with testnet head.

It does take some time to catchup, the exact time depends on the computer. For example on mainnet it takes upward of 11 hours to do so. On testnet it should be less, a couple of hours.

After the node is caught up it will still print new messages in the log. Every 10s on average it will print a new block, since that is the time a new block is baked by the network on average.

Your configuration otherwise looks correct, although I would recommend changing the node name away from docker-test since that is the name used in examples.