Detect unclean shutdowns

[ligi]

it would be nice if geth could detect if geth was not shutdown correctly (e.g. it crashed)
then the user could be offered the upcoming tooling: #20858. Also it will help us investigate issues like #20845

[MariusVanDerWijden]

This is a great first issue if someone wants to pick it up! I've created a PoC here: https://github.com/MariusVanDerWijden/go-ethereum/tree/unclean-shutdowns
Problem with this is

• The logic is at the wrong place
• The code is not really clean
• If we detected an unclean shutdown at the start, the shutdown should not be erased after the next successful shutdown
• The code does not use the nice logging style

Feel free to pick this issue up if you want to start contributing to go-ethereum
If you need any help, ping me on gitter or here

[muhammednagy]

Hey i can pick this issue up if no one else has taken it.
Feel free to assign it to me @MariusVanDerWijden

[ligi]

@muhammednagy great! I just assigned you - enjoy working on it and let us know if you run into problems

[muhammednagy]

@MariusVanDerWijden

If we detected an unclean shutdown at the start, the shutdown should not be erased after the next successful shutdown

When should it be erased then?
or should it be not erased at all?
could probably add timestamp to the unclean shutdown file name.

could change it from unclean-shutdown-timestamp to read-unclean-shutdown-timestamp if we don't want to delete it.

[ligi]

IMHO we should not throw away any of these files automatically. These can be very valuable to debug problems and the more info we can get the better I would say. And yes a timestamp in the file is a good idea

[karalabe]

I would not put these into external files at all. Placing them into leveldb is a much much better idea because we don't have to track yet another files which need to be placed in the correct datadir, etc. We did the same with the snapshot diffs and it makes things so much cleaner all around.

[ligi]

Also an option - but we need to make sure a corrupted database will not be a blocker from accessing these logs.

[karalabe]

The database doesn't get corrupted (unless your hard drive fails).

[muhammednagy]

I think database is a better option.
I will start working on that.
Thanks @karalabe & @ligi

[FridayOrtiz]

For anyone else experiencing this, the fix is pending PR #21893.