Troubleshooting: Run a node
The guidance displayed on this page will change based on your selected configuration:
- Operating system:
- Linux, MacOS, Arm64
- Windows
- Network:
- Arbitrum One (Nitro)
- Arbitrum One (Classic)
- Arbitrum Nova
- Arbitrum Sepolia
- Localhost
- Node type:
- Full node
- Archive node
- Validator node
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.
Step 2: Look for your scenario
Common troubleshooting scenarios and solutions are detailed below.
| Scenario | Solution |
|---|---|
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. |
Step 3: Generate a troubleshooting report
- Complete the above troubleshooting checklist.
- Fill in the below form.
- Click
Generate troubleshooting report. - 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_IDGenerate troubleshooting report