LND will not start; issue with opening the graph database

[Koola-T]

My node crashed, so I rebooted the machine. After restarting, I was able to bring all services back online except LND. The relevant error in the LND log states “LTND: unable to open graph DB: ReadVarBytes; sig is larger than the max allowed size [count 179, max 80]”. I would appreciate any guidance on how to resolve this issue and get LND functioning again.

[guggero]

Sounds like the database suffered data corruption due to the unclean shutdown.
You can try chantools compactdb. If that succeeds without errors, you should be able to continue using the node.
If there are errors, you might need to do the emergency recovery procedure which unfortunately involves closing all channels.

[SnowyLND]

Hi, @guggero. I'm having a similar problem.

The relevant error in the log is ¨panic: assertion failed: Page expected to be: 1516, but self identifies as 504403159808323950¨

I tried chantools and the output was ¨[INF] CHAN: chantools version v0.13.4 commit
panic: runtime error: index out of range [754368882103230464] with length 281474976710655¨

followed by

¨goroutine 1 [running]:
github.com/coreos/bbolt.(*DB).page(...)
github.com/coreos/[email protected]/db.go:886
github.com/coreos/bbolt.(*Tx).page(...)
github.com/coreos/[email protected]/tx.go:620
github.com/coreos/bbolt.(*Bucket).pageNode(0x400048f768?, 0x3d60a780e805f5f2)
github.com/coreos/[email protected]/bucket.go:724 +0x110
github.com/coreos/bbolt.(*Cursor).first(0x400048f838)
github.com/coreos/[email protected]/cursor.go:181 +0xc4
github.com/coreos/bbolt.(*Cursor).First(0x400048f838)
github.com/coreos/[email protected]/cursor.go:36 +0x114
github.com/coreos/bbolt.(*Bucket).ForEach(0x40000fe280?, 0x400048f880)
github.com/coreos/[email protected]/bucket.go:387 +0x5c
github.com/coreos/bbolt.(*Tx).ForEach(0x400048f928?, 0x40001319b8?)
github.com/coreos/[email protected]/tx.go:128 +0x44
main.(*compactDBCommand).compact.(*compactDBCommand).walk.func3(0x400033a1c0?)
github.com/lightninglabs/chantools/cmd/chantools/compactdb.go:182 +0x44
github.com/coreos/bbolt.(*DB).View(0x4000131800?, 0x400048f9e8)
github.com/coreos/[email protected]/db.go:725 +0x70
main.(*compactDBCommand).walk(...)
github.com/lightninglabs/chantools/cmd/chantools/compactdb.go:181
main.(*compactDBCommand).compact(0x40002a8720, 0x4000131a00, 0x4000131800)
github.com/lightninglabs/chantools/cmd/chantools/compactdb.go:109 +0xe8
main.(*compactDBCommand).Execute(0x40002a8720, 0x0?, {0x0?, 0x4000306b00?, 0xec5510?})
github.com/lightninglabs/chantools/cmd/chantools/compactdb.go:76 +0x180
github.com/spf13/cobra.(*Command).execute(0x4000193088, {0x400023a2c0, 0x4, 0x4})
github.com/spf13/[email protected]/command.go:852 +0x568
github.com/spf13/cobra.(*Command).ExecuteC(0x245a4e0)
github.com/spf13/[email protected]/command.go:960 +0x310
github.com/spf13/cobra.(*Command).Execute(...)
github.com/spf13/[email protected]/command.go:897
main.main()
github.com/lightninglabs/chantools/cmd/chantools/root.go:139 +0x39c¨

Do you think in this case I'll have to resort to the emergency recovery procedure ?

[guggero]

Yes, unfortunately this is the classic symptom of a corrupted database.

[SnowyLND]

Thank you.