> ## Documentation Index
> Fetch the complete documentation index at: https://optimism-373f39ad-soyboy-docs-deploy-a-contract.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Node Troubleshooting

> Learn solutions to common problems to troubleshoot your node.

This page lists common troubleshooting scenarios and solutions for node operators.

## 401 Unauthorized: Signature Invalid

If you see a log that looks like this in `op-node`:

```
WARN [12-13|15:53:20.263] Derivation process temporary error       attempts=80 err="stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch current L2 forkchoice state: failed to find the finalized L2 block: failed to determine L2BlockRef of finalized, could not get payload: 401 Unauthorized: signature is invalid
```

It means that the `op-node` is unable to authenticate with `execution client`'s authenticated RPC using the JWT secret.

### Solution

1. Check that the JWT secret is correct in both services.
2. Check that `execution client`'s authenticated RPC is enabled, and that the URL is correct.

## Failed to Load P2P Config

If you see a log that looks like this in `op-node`:

```
CRIT [12-13|13:46:21.386] Application failed                       message="failed to load p2p config: failed to load p2p discovery options: failed to open discovery db: mkdir /p2p: permission denied"
```

It means that the `op-node` lacks write access to the P2P discovery or peerstore directories.

### Solution

1. Make sure that the `op-node` has write access to the P2P directory. By default, this is `/p2p`.
2. Set the P2P directory to somewhere the `op-node` can access via the `--p2p.discovery.path` and `--p2p.peerstore.path` parameters.
3. Set the discovery path to `memory` to disable persistence via the `--p2p.discovery.path` and `--p2p.peerstore.path` parameters.

## Wrong Chain

If you see a log that looks like this in `op-node`:

```
{"attempts":183,"err":"stage 0 failed resetting: temp: failed to find the L2 Heads to start from: wrong chain L1: genesis: 0x4104895a540d87127ff11eef0d51d8f63ce00a6fc211db751a45a4b3a61a9c83:8106656, got 0x12e2c18a3ac50f74d3dd3c0ed7cb751cc924c2985de3dfed44080e683954f1dd:8106656","lvl":"warn","msg":"Derivation process temporary error","t":"2022-12-13T23:31:37.855253213Z"}
```

It means that the `op-node` is pointing to the wrong chain.

### Solution

1. Verify that the `op-node`'s L1 URL is pointing to the correct L1 for the given network.
2. Verify that the `op-node`'s rollup config/`--network` parameter is set to the correct network.
3. Verify that the `op-node`'s L2 URL is pointing to the correct instance of `execution client`, and that `execution client` is properly initialized for the given network.

## Error: `eth_sendRawTransaction` Does Not Exist

If an RPC call to your execution client (`op-reth`, Nethermind, etc.) returns a response like:

```json theme={null}
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32601,
    "message": "the method eth_sendRawTransaction does not exist/is not available"
  }
}
```

This `-32601` JSON-RPC error means the sequencer endpoint you configured does not expose `eth_sendRawTransaction`. The request path looks like:

```
Client → eth_sendRawTransaction → execution client:8545
                                ↓
                  EL forwards to sequencer (--rollup.sequencer URL)
                                ↓
              eth_sendRawTransaction → op-node:8547
                                ↓
              ❌ ERROR: "method does not exist/is not available"
                 (op-node has no eth namespace!)
```

Because `op-node` only exposes rollup-specific RPC methods—there is no `eth_*` namespace—it cannot accept raw transaction submissions. When your execution client forwards the transaction to an `op-node` URL it immediately fails with `-32601`.

This situation almost always happens when op-reth's `--rollup.sequencer` (aliases `--rollup.sequencer-http`, `--rollup.sequencer-ws`) is misconfigured to point at your own `op-node` rather than the chain's actual sequencer.

### Solution

1. Confirm op-reth exposes the `eth` namespace on its HTTP API (the standard set is `--http.api=eth,net,web3,debug`). If `eth` is disabled, raw transactions will be rejected before they reach the sequencer.
2. Inspect the CLI flags and environment variables of every component that talks to the sequencer (`op-node`, `op-reth`, `op-batcher`, `op-proposer`, scripts). The `--rollup.sequencer` flag must point to the chain's public sequencer endpoint (for example, `https://mainnet-sequencer.optimism.io`), **not** to your own `op-node`.
3. For user-deployed L2s where you run the sequencer yourself, leave `--rollup.sequencer` unset so op-reth forwards locally and never falls back to an `op-node` endpoint.
4. Restart the affected services after correcting the flag so they pick up the new endpoint. The error should disappear as soon as they can reach the proper sequencer RPC.

## Unclean Shutdowns

An unclean shutdown occurs when the execution client stops without completing its normal shutdown procedure — for example, a `SIGKILL`, a power loss, or a container killed past its grace period. The impact depends on which database backend your EL uses.

To minimize risk, always shut down gracefully: `Ctrl-C` for foreground processes, `docker stop -t 300 <container>` for Docker, or `systemctl stop` for systemd (override the default 90s timeout if your EL has a large in-memory write to flush).

### For op-reth

op-reth uses MDBX, which is crash-safe by design. After an unclean shutdown the node typically restarts cleanly with no operator intervention required.

If startup fails after an unclean shutdown, options include:

* **Stage unwind** — roll back to the last consistent stage checkpoint:

  ```bash theme={null}
  op-reth stage unwind to-block <BLOCK_NUMBER> --datadir=<path>
  ```

* **Full resync** — as a last resort, delete the datadir and resync from genesis or a [snapshot](https://datadirs.optimism.io/).

### For Nethermind

Unclean shutdowns in `Nethermind` can lead to database corruption. This typically happens when:

* The node experiences hardware failures (disk failures, memory errors, overheating)
* Power cuts cause abrupt shutdowns
* The process is terminated without proper cleanup

**Solutions**

1. **Lock File Issues**

   If `Nethermind` complains about lock files after an unclean shutdown, run:

   ```bash theme={null}
   find /path/to/nethermind_db -type f -name 'LOCK' -delete
   ```

2. **Block Checksum Mismatch**

   If you encounter block checksum mismatch errors, you can enable direct I/O:

   ```bash theme={null}
   --Db.UseDirectIoForFlushAndCompactions true
   ```

   Note: This may impact performance.

3. **Complete Resync**

   In cases of severe corruption, a full resync is recommended:

   ```bash theme={null}
   sudo systemctl stop nethermind
   sudo rm -rf /path/to/nethermind_db/mainnet
   sudo systemctl start nethermind
   ```