mirror of https://github.com/ethereum/go-ethereum
Joe
2 years ago
parent
79bd2a1e83
commit
e54b879469
@ -0,0 +1,159 @@ |
||||
--- |
||||
title: Geth logs |
||||
description: Geth's log messages explained |
||||
--- |
||||
|
||||
A Geth node continually reports messages to the console allowing users to monitor Geth's current status in real-time. The logs indicate when Geth is running normally and indicates when some attention is required. However, reading these logs can be difficult for new users. This page will help to interpret the log messages to better understand what Geth is doing. |
||||
|
||||
## Configuring log messages |
||||
|
||||
Log messages are displayed to the console by default. The messages can be tuned to be more or less detailed by passing `--verbosity` and a value between 0 and 6 to Geth at startup: |
||||
|
||||
```sh |
||||
0 = silent (no log messages) |
||||
1 = error (error messages only) |
||||
2 = warn (error messages and warnings only) |
||||
3 = info (error messages, warnings and normal activity logs) |
||||
4 = debug (all info plus additional messages for debugging) |
||||
5 = detail (all info plus detailed debugging messages) |
||||
``` |
||||
The default is `--verbosity 3`. |
||||
|
||||
Log messages can also be redirected so they are saved to a text file instead of being displayed in the console. In Linux the syntax `>> <path> 2>&1` redirects both `stdout` and `stderr` messages to `<path>`. For example: |
||||
|
||||
```sh |
||||
# saves detailed logs to path/eth.log |
||||
geth --verbosity 5 >> /path/eth.log 2>&1 |
||||
``` |
||||
|
||||
### Startup |
||||
|
||||
When Geth starts up it immediately reports a fairly long page of configuration details and status reports that allow the user to confirm Geth is on the right network and operating in its intended modes. The b asic structure of a log message is as follows: |
||||
|
||||
``` |
||||
MESSAGE_TYPE [MONTH-DAY][TIME] MESSAGE VALUE |
||||
``` |
||||
Where `MESSAGE_TYPE` can be `INFO`, `WARN`, `ERROR` or `DEBUG`. These tags categorize log messages according to their purpose. `INFO` messages inform the user about Geth's current configuration and status. `WARN` messages are for alerting the user to details that may affect the way Geth is going to continue running. `ERROR` messages are for alerting the user to problems. `DEBUG` is for messages that are relevant to troubleshooting or for developers working on Geth. |
||||
|
||||
The messages displayed on startup break down as follows: |
||||
|
||||
``` |
||||
INFO [10-04|10:20:52.028] Starting Geth on Ethereum mainnet... |
||||
INFO [10-04|10:20:52.028] Bumping default cache on mainnet provided=1024 updated=4096 |
||||
INFO [10-04|10:20:52.030] Maximum peer count ETH=50 LES=0 total=50 |
||||
INFO [10-04|10:20:52.031] Smartcard socket not found, disabling err="stat /run/pcscd/pcscd.comm: no such file or directory" |
||||
INFO [10-04|10:20:52.034] Set global gas cap cap=50,000,000 |
||||
INFO [10-04|10:20:52.035] Allocated trie memory caches clean=614.00MiB dirty=1024.00MiB |
||||
INFO [10-04|10:20:52.035] Allocated cache and file handles database=/home/go-ethereum/devnet/geth/chaindata cache=2.00GiB handles=524,288 |
||||
INFO [10-04|10:20:52.128] Opened ancient database database=/home/go-ethereum/devnet/geth/chaindata/ancient/chain readonly=false |
||||
INFO [10-04|10:20:52.129] Disk storage enabled for ethash caches dir=/home/go-ethereum/devnet/geth/ethash count=3 |
||||
INFO [10-04|10:20:52.129] Disk storage enabled for ethash DAGs dir=/home/.ethash count=2 |
||||
INFO [10-04|10:20:52.129] Initialising Ethereum protocol network=1 dbversion=<nil> |
||||
INFO [10-04|10:20:52.129] Writing default main-net genesis block |
||||
INFO [10-04|10:20:52.372] Persisted trie from memory database nodes=12356 size=1.78MiB time=21.535537ms gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B |
||||
``` |
||||
|
||||
This block of logs shows the user that the node is connecting to Ethereum Mainnet and some low level configuration details. The cache size is bumped to the Mainnet default (4096). The maximum peer count is the highest number of peers this node is allowed to connect to and can be used to control the bandwidth requirements of the node. Logs relating to `ethash` are out of date since Ethereum moved to proof-of-stake based consensus and can safely be ignored. |
||||
|
||||
|
||||
``` |
||||
--------------------------------------------------------------------------------------------------------------------------------------------------------- |
||||
INFO [10-04|10:20:52.386] Chain ID: 1 (mainnet) |
||||
INFO [10-04|10:20:52.386] Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work) |
||||
INFO [10-04|10:20:52.386] |
||||
INFO [10-04|10:20:52.386] Pre-Merge hard forks: |
||||
INFO [10-04|10:20:52.386] - Homestead: 1150000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/homestead.md) |
||||
INFO [10-04|10:20:52.386] - DAO Fork: 1920000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/dao-fork.md) |
||||
INFO [10-04|10:20:52.386] - Tangerine Whistle (EIP 150): 2463000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/tangerine-whistle.md) |
||||
INFO [10-04|10:20:52.386] - Spurious Dragon/1 (EIP 155): 2675000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/spurious-dragon.md) |
||||
INFO [10-04|10:20:52.386] - Spurious Dragon/2 (EIP 158): 2675000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/spurious-dragon.md) |
||||
INFO [10-04|10:20:52.386] - Byzantium: 4370000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/byzantium.md) |
||||
INFO [10-04|10:20:52.386] - Constantinople: 7280000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/constantinople.md) |
||||
INFO [10-04|10:20:52.386] - Petersburg: 7280000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/petersburg.md) |
||||
INFO [10-04|10:20:52.386] - Istanbul: 9069000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/istanbul.md) |
||||
INFO [10-04|10:20:52.387] - Muir Glacier: 9200000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/muir-glacier.md) |
||||
INFO [10-04|10:20:52.387] - Berlin: 12244000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.md) |
||||
INFO [10-04|10:20:52.387] - London: 12965000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/london.md) |
||||
INFO [10-04|10:20:52.387] - Arrow Glacier: 13773000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/arrow-glacier.md) |
||||
INFO [10-04|10:20:52.387] - Gray Glacier: 15050000 (https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/gray-glacier.md) |
||||
``` |
||||
|
||||
The above block of messages are related to past Ethereum hard forks. The names are the names of the hard forks and the numbers are the blocks at which the hard fork occurs. This means that blocks with numbers that exceed these values have the configuration required by that hard fork. The specification of each hard fork is available at the provided links (and more information is available on [ethereum.org](https://ethereum.org/en/history/)). The message `Consensus: Beacon (proof-of-stake), merged from Ethash (proof-of-work)` indicates that the node requires a Beacon node to follow the canonical chain - Geth cannot participate in consensus on its own. |
||||
|
||||
``` |
||||
INFO [10-04|10:20:52.387] Merge configured: |
||||
INFO [10-04|10:20:52.387] - Hard-fork specification: https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md |
||||
INFO [10-04|10:20:52.387] - Network known to be merged: true |
||||
INFO [10-04|10:20:52.387] - Total terminal difficulty: 58750000000000000000000 |
||||
INFO [10-04|10:20:52.387] - Merge netsplit block: <nil> |
||||
INFO [10-04|10:20:52.387] |
||||
INFO [10-04|10:20:52.388] Chain post-merge, sync via beacon client |
||||
WARN [10-04|10:20:52.388] Engine API enabled protocol=eth |
||||
--------------------------------------------------------------------------------------------------------------------------------------------------------- |
||||
``` |
||||
|
||||
The messages above relate to [The Merge](https://ethereum.org/en/upgrades/merge/). The Merge was Ethereum's transition from proof-of-work to proof-of-stake based consensus. In Geth, The Merge came in the form of the Paris hard fork which was triggered at a [terminal total difficulty](https://ethereum.org/en/glossary/#terminal-total-difficulty) of 58750000000000000000000 instead of a preconfigured block number like previous hard forks. The hard fork specification is linked in the log message. The message `network known to be merged: true` indicates that the node is following a chain that has passed the terminal total difficulty and undergone the Paris hard fork. Since September 15 2022 this will always be true for nodes on Ethereum Mainnet (and the merged testnets Sepolia and Goerli). The warning `Engine API enabled` informs the user that Geth is exposing the set of API methods required for communication with a consensus client. |
||||
|
||||
``` |
||||
INFO [10-04|10:20:52.389] Starting peer-to-peer node instance=Geth/v1.11.0-unstable-e004e7d2-20220926/linux-amd64/go1.19.1 |
||||
INFO [10-04|10:20:52.409] New local node record seq=1,664,875,252,408 id=9aa0e5b14ccd75ec ip=127.0.0.1 udp=30303 tcp=30303 |
||||
INFO [10-04|10:20:52.409] Started P2P networking self=enode://1ef45ab610c2893b70483bf1791b550e5a93763058b0abf7c6d9e6201e07212d61c4896d64de07342c9df734650e3b40812c2dc01f894b6c385acd180ed30fc8@127.0.0.1:30303 |
||||
INFO [10-04|10:20:52.410] IPC endpoint opened url=/home/go-ethereum/devnet/geth.ipc |
||||
INFO [10-04|10:20:52.410] Generated JWT secret path=/home/go-ethereum/devnet/geth/jwtsecret |
||||
INFO [10-04|10:20:52.411] HTTP server started endpoint=127.0.0.1:8545 auth=false prefix= cors= vhosts=localhost |
||||
INFO [10-04|10:20:52.411] WebSocket enabled url=ws://127.0.0.1:8551 |
||||
INFO [10-04|10:20:52.411] HTTP server started endpoint=127.0.0.1:8551 auth=true prefix= cors=localhost vhosts=localhost |
||||
INFO [10-04|10:20:54.785] New local node record seq=1,664,875,252,409 id=9aa0e5b14ccd75ec ip=82.11.59.221 udp=30303 tcp=30303 |
||||
INFO [10-04|10:20:55.267] Mapped network port proto=udp extport=30303 intport=30303 interface="UPNP IGDv1-IP1" |
||||
INFO [10-04|10:20:55.833] Mapped network port proto=tcp extport=30303 intport=30303 interface="UPNP IGDv1-IP1" |
||||
INFO [10-04|10:21:03.100] Looking for peers peercount=0 tried=20 static=0 |
||||
``` |
||||
|
||||
The logs above relate to Geth starting up its peer-to-peer components and seeking other nodes to connect to. The long address reported to `Started P2P networking` is the nodes own enode address. The `IPC Endpoint` is the location of the node's IPC file that can be used to connect a Javascript console. There is a log message confirming that a JWT secret was generated and reporting its path. This is required to authenticate communication between Geth and the consensus client. There are also messages here reporting on the HTTP server that can be used to send requests to Geth. There should be two HTTP servers - one for interacting with Geth (defaults to `localhost:8545`) and one for communication with the consensus client (defaults to `localhost:8551`). |
||||
|
||||
|
||||
### Syncing |
||||
|
||||
The default for Geth is to sync in snap mode. This requires a block header to be provided to Geth by the consensus client. The header is then used as a target to sync to. Geth requests block headers from its peers that are parents of the target until there is a continuous chain of sequential headers of sufficient length. Then, Geth requests block bodies and receipts for each header and simultaneously starts downloading state data. This state data is stored in the form of a [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/). Only the leaves of the trie are downloaded, the full trie structure is then locally regenerated from the leaves up. Meanwhile, the blockchain continues to progress and the target header is updated. This means some of the regenerated state data needs to be updated. This is known as *healing*. |
||||
|
||||
Assuming Geth has a synced consensus client and some peers it will start importing headers, block bodies and receipts. The log messages for data downloading look as follows: |
||||
|
||||
``` |
||||
INFO [07-28|10:29:50.427] Imported new block headers count=1 elapsed=253.434ms number=12,914,945 hash=ee1a08..9ce38a |
||||
INFO [07-28|10:30:00.224] Imported new block receipts count=64 elapsed=13.703s number=12,914,881 hash=fef964..d789fc age=18m5s size=7.69MiB |
||||
INFO [07-28|10:30:18.658] Imported new block headers count=1 elapsed=46.715ms number=12,914,946 hash=7b24c8..2d8006 |
||||
``` |
||||
|
||||
For state data |
||||
|
||||
``` |
||||
INFO [07-28|10:30:21.965] State heal in progress accounts=169,633@7.48MiB slots=57314@4.17MiB codes=4895@38.14MiB nodes=43,293,196@11.70GiB pending=112,626 |
||||
INFO [07-28|10:30:21.969] State heal in progress accounts=169,633@7.48MiB slots=57314@4.17MiB codes=4895@38.14MiB nodes=43,293,196@11.70GiB pending=112,626 |
||||
``` |
||||
|
||||
|
||||
```sh |
||||
# consensus client has identified a new head to use as a sync target - account for this in state sync |
||||
INFO [10-03|15:34:01.336] Forkchoice requested sync to new head number=15,670,037 hash=84d4ec..4c0e2b |
||||
|
||||
``` |
||||
|
||||
|
||||
|
||||
## Common Error messages |
||||
|
||||
|
||||
```sh |
||||
# the following indicates a request timeout, may indicate IO speed is low. |
||||
WARN [10-03|18:00:40.413] Unexpected trienode heal packet peer=9f0e8fbf reqid=6,915,308,639,612,522,441 |
||||
``` |
||||
|
||||
```sh |
||||
# no consensus client |
||||
WARN [10-03|13:10:26.441] Post-merge network, but no beacon client seen. Please launch one to follow the chain! |
||||
``` |
||||
|
||||
```sh |
||||
# consensus client is not working, most likely it is not in sync yet - swapping cl to checkpoint sync is fastest |
||||
WARN [10-03 |13:10:26.499] Beacon client online, but never received consensus updates. Please ensure your beacon client is operational to follow the chain! |
||||
``` |
||||
Loading…
Reference in new issue