main.cpp:6810: void ProcessGetData(CNode*): Assertion `!"cannot load block from disk"' failed #102

For now it is only for tracking purposes, one of my nodes that is running on Ubuntu 20 crashed with some weird message that I see for the first time, running it again didn't cause any problems, it was a "one-time thing".

readblockfromdisk err B
hushd: main.cpp:6810: void ProcessGetData(CNode*): Assertion `!"cannot load block from disk"' failed. Aborted

https://git.hush.is/hush/hush3/src/branch/master/src/main.cpp#L6810

@onryo if this happened on a VPS, it means your disk io was limited by the company.

If it happened on your own physical server it could mean a disk is starting to fail

@onfyo FYI I dealt with this same error for months on my server which was using to much disk io from Redis. It may happen to you again. One thing is to run a cron that looks for hushd running, and if not, restart it. Another is to optimize your server to use less disk io.

I looked into changing the code so it doesn't assert() but the internals are written in such a way that it's very hard to change.

@duke that server is not using redis, it is just a regular node, but with a zindex feature that I use to render my anonset data, and I experienced the error once and no other errors were found for the past 6 months at least.

@onryo if it's a VPS, see if you can check your disk io usage graphs, if you have them. Many other things can use disk io, other than redis. Such as a cron that does backups. Most VPS's only allow so much disk io per unit of time, and if you use more, they don't give it to you, which triggers these errors.

If it's a physical server, it could be a sign of a failing HD.

@duke I found a IOPS spike (62) when that error has happened, about x300 difference from regular days, also Outgoing traffic, GiB/packets: 8.5 spike.

 2022-01-29 20:00:00 0.1513 GiB / 947533 3.2172 GiB / 1043529 684054690 61.3739 iops / 1.88 MB/s

 2022-01-29 21:00:00 0.1506 GiB / 1918499 8.4841 GiB / 2279689 685232091 3.4206 iops / 51.44 KB/s

@onryo yep, that is likely what caused it. Perhaps it was a bot hammering your server

@onryo You can put this stuff in each server { } block you have in nginx to reduce stupid bot shite:

        # Get the fuck off my lawn motherfuckerz
        if ($request_method !~ ^(GET|HEAD|POST)$ ) { return 444; }

        # fuck these bots
       if ($http_user_agent ~* "Googlebot|YandexBot|bingbot|applebot|Mojeekbot|ICC-Crawler|SemrushBot|xforce-security.com|TestBot|MauiBot|CCBot|SummalyBot|PetalBot|BLEXBot|expanseinc.com|clark-crawler|AhrefsBot|mj12bot|YisouSpider|opensiteexplorer|seznambot|dataforseo|Adsbot|Neevabot") {
                 return 444;
       }

        location ~* .(display_errors|set_time_limit|allow_url_include.*disable_functions.*open_basedir|set_magic_quotes_runtime|webconfig.txt.php|file_put_contentssever_root|wlwmanifest) {
                return 444;
        }

        location ~* ^/wp-content/.*$ {
                 return 444;
        }

closing this as it is an expected error