# Troubleshooting

> Troubleshooting the Mesa upgrade — checking which binary your node is running, dispatcher behavior, and debug mode for automode operators.

Canonical URL: https://docs.minaprotocol.com/network-upgrades/mesa/troubleshooting

This page collects common operator questions and debugging tips for the Mesa upgrade. For low-level architecture and dispatcher internals, see [Upgrade Modes — Details](/network-upgrades/mesa/appendix/upgrade-modes-details).

## How do I know which binary my node is using?

Check whether the activation state file exists. The file is located at:

`{config-directory}/auto-fork-mesa-{network_id}/activated`

Where:
- `{config-directory}` is the path passed via `--config-directory` (defaults to `~/.mina-config` on the host, or `/root/.mina-config` in Docker)
- `{network_id}` is the network name (e.g., `mainnet` or `devnet`)

For example, on a typical mainnet setup:

```bash
ls ~/.mina-config/auto-fork-mesa-mainnet/activated
```

- **File does not exist**: your node is using the pre-fork (Berkeley) binary
- **File exists**: your node has transitioned to the Mesa binary

## Can I run non-daemon commands or use a specific binary version?

As described in [Dispatcher Limitations](/network-upgrades/mesa/appendix/upgrade-modes-details#dispatcher-limitations), the dispatcher supports `daemon`, `client`, and `--version`. For any other command — including `accounts list`, `ledger export`, and other CLI operations — **you must use the version-specific binary directly**:

| Binary | Description | Full path |
|---|---|---|
| Pre-fork (Berkeley) | Current chain | `/usr/lib/mina/berkeley/mina` |
| Post-fork (Mesa) | Mesa chain | `/usr/lib/mina/mesa/mina` |

```bash
# Use the Mesa binary for all non-daemon commands after the fork
/usr/lib/mina/mesa/mina client status
/usr/lib/mina/mesa/mina accounts list
/usr/lib/mina/mesa/mina ledger export

# Use the Berkeley binary for pre-fork queries
/usr/lib/mina/berkeley/mina client status
```

Both binaries are installed at these fixed paths by the automode packages and are always available. They bypass the dispatcher entirely and run the binary directly, so they work regardless of the activation state. (There is no `mina-mesa` or `mina-berkeley` command on `PATH` — invoke the binaries by their full paths.)

:::caution Do not manipulate the activation state file
While it is technically possible to force the dispatcher to use a specific runtime by creating or removing the `activated` file, **this is strongly discouraged**. Manually manipulating the state file while the network is live can put your node on the wrong chain. If you need to run a specific version, invoke the full binary path (`/usr/lib/mina/berkeley/mina` or `/usr/lib/mina/mesa/mina`) directly instead.
:::

## Debug mode

Set `MINA_DISPATCHER_DEBUG=1` in your environment to see which binary and arguments the dispatcher is using:

```bash
MINA_DISPATCHER_DEBUG=1 mina daemon ...
```

For a dry run (print the command without executing):

```bash
MINA_DISPATCHER_DRYRUN=1 mina daemon ...
```