Skip to main content

Troubleshooting: Run a node

The guidance displayed on this page will change based on your selected configuration:

Thank you!

At the end of this troubleshooting guide, you'll find a "Generate troubleshooting report" button. Clicking this button will generate a report that includes your selected configuration. You can include this report when asking for help.

Using this page to generate a troubleshooting report is helpful because it gathers the information that we need in order to resolve your issue.

Step 1: Try the troubleshooting checklist​

If you're running into unexpected outputs or errors, the following checklist may help you independently resolve your issue.

The guidance displayed on this page will change based on your selected configuration.

The How to run a full node (Nitro) may address your issue.

Answers to frequently asked questions can be found in Frequently asked questions: Run a node.

Step 2: Look for your scenario​

Common troubleshooting scenarios and solutions are detailed below.

ScenarioSolution

You see Unindex transactions.

This is expected behavior. You'll see this when your node removes old txlookup indices. This is emitted from the base Geth node, so you'd see the same output from a mainnet Geth node.

You see Head state missing, repairing.

This is usually because your node shut down ungracefully. In most cases it will recover in few minutes, but if it not, you may have to re-sync your node. Remember to shut down your node gracefully with the following command: docker stop —time=300 $(docker ps -aq).

You see failed to read inbox messages

This is usually because either A) your L1 RPC is unreachable or B) your L1 node hasn't finished syncing and an old L1 node's state that doesn't have our inbox contracts deployed is being used. Check your L1 RPC sync status and connection status, or consider using another L1 RPC to isolate the issue.

Your local machine is running out of memory

Nitro (and Geth) can consume a lot of memory depending on request load. It's possible that your machine may run out of memory when receiving tons of requests.

Your Arbitrum node can’t connect to your L1 node on localhost:8545

This is often because of a Docker port configuration issue. See https://stackoverflow.com/questions/43884981/unable-to-connect-localhost-in-docker.

You specified your snapshot file path via the --init.url parameter, but the snapshot file isn't found.

This is usually because the snapshot file isn't mounted to your Docker container. Mount it and change the file path to your Docker container’s mount point.

You get 403 errors from the feed URL.

This often happens when Cloudflare attempts to block botnets and other malicious actors, but accidentally ends up blocking node runners.

You see

failed to get blobs: expected at least 6 blobs for slot [slot_number] but only got 0

This often happens when you connect to a beacon chain endpoint while the blob you are querying is expired. To resolve this error, connect to a beacon endpoint which supports historical blob data (see

List of Ethereum beacon chain RPC providers

).

Step 3: Generate a troubleshooting report​

  1. Complete the above troubleshooting checklist.
  2. Fill in the below form.
  3. Click Generate troubleshooting report.
  4. Copy and paste the generated report text when asking for support on Discord or any other support channel.

Node startup command (make sure to remove any sensitive information like, i.e., private keys)

Unexpected output

Tip: Paste the ~100 lines of output before and including the unexpected output you're asking about. You can use the following command to get the logs:

docker logs --tail 100 YOUR_CONTAINER_ID

Generate troubleshooting report

Complete the checklist above before generating...

Last updated on