Fatal: Failed to register the Ethereum service: content truncated #29303
Labels
Comments
|
I managed to get the logs (from a separate device but configured the same way) generated by geth with no actions taken to change the state ( |
|
@holiman It's an error raised from billy. Probably something wrong? |
|
Yes, this comes from
blobpool/limbo.go func (p *BlobPool) Init{
...
store, err := billy.Open(billy.Options{Path: queuedir, Repair: true}, newSlotter(), index)
...
func newLimbo(datadir string) (*limbo, error) {
...
store, err := billy.Open(billy.Options{Path: datadir}, newSlotter(), index)If we wanted billy to just repair it and move on, we have to supply the billy.Options{Path: datadir, Repair: true}I am not sure why the current code does not do that on both callsites, if it's just an oversight or a conscious decision. @karalabe ? Tangential: It would be nice if the the error message could tell us what file it concerns, in case we'd want to investigate the file. Or manually truncate it to a correct size. |
|
So, this must be in the second location. One of the files in Other than that, I think the easiest way to resolve this is to delete the file. |
|
@holiman Thank you for your help. |
|
+1 saw the same thing just now. 1 thing to mention, I was not able to get into the machine remotely and suspect the node crashed so restarted it. once the geth container started, it resulted in the error as @jimmyisthis sees above followed the same course as above to find the faulty file in the here is the file I deleted if that helps debug further |
I'd say oversight. The original issue was fixed in https://github.com/ethereum/go-ethereum/pull/29001/files and I probably forgot that we have a second Billy in there. There's no reason not to do a repair on the limbo. Worst case is the same as for the mail billy, that we lose some transactions and cannot resurrect them in our local node on a reorg. But that's fine, network has redundancy so losing a blob locally is fine. These dbs are temporary storage only, not long term. TL;DR: We should add repair to the limbo too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Geth version:
1.13.14-stable-2bd6bd01CL client & version:
Lighthouse/v5.1.0-10a38a8OS & Version: Linux (Ubuntu 23.10) on Raspberry Pi 5
Expected behaviour
Node starts normally and geths starts catching up the current chain head.
Actual behaviour
Client starts, but almost immediately fails with
Fatal: Failed to register the Ethereum service: content truncated, size:802805, slot:266240message. Logs:Steps to reproduce the behaviour
geth --authrpc.addr=0.0.0.0 --authrpc.port 8551 --authrpc.vhosts=* --authrpc.jwtsecret SECRET_LOCATION --http --http.addr 0.0.0.0 --http.vhosts=* --http.api eth,net,web3 --state.scheme=pathlighthouse bn --network mainnet --execution-endpoint http://localhost:8551 --execution-jwt SECRET_LOCATION --checkpoint-sync-url https://mainnet.checkpoint.sigp.io --disable-deposit-contract-syncgeth removedband remove the state database, but keep the ancient stateRemarks:
geth removedbstep, which I ran to check if that would fix the issue on my endThe text was updated successfully, but these errors were encountered: