It complains that it cannot find older blkXXXXX.dat files, in this case blk02641.dat. Can you confirm that file is in your blockchain data folder? Im going to assume it is for the remainder of this post.
"ArmoryDB --db-type=DB_BARE --ram-usage=1"
This setting is too approximative, the main way to clamp memory usage in ArmoryDB is by reducing thread count (--thread-count=X).
I don't know how memory is managed between containers and host. I've ran into the oomkiller a few times when running beefy containers + using a bunch of memory on the host (im on arch) and while the system recovers, a lot of processes blow up unpredictably. I can't tell if you're running in this issue because of corrupted data or because of weirdness with resource load within containers.
My suspicion is that a parser thread dies mid scan and you're seeing the consequences of that (block files are grabbed as whole, this would explain one file failing to scan entirely). --ram-usage controls how many block files can be parsed concurrently. Bitcoin Core keeps block files within 128MB so that's a proxy for memory usage in ArmoryDB. --thread-count limits the amount of threads the scanner gets to use and is a better predictor of resource load.
This is what I suggest for now:
1. Try to rescan (not rebuild) your db. If it fails at a different block file, then you are running into a concurrency issue. Toy with --ram-usage and --thread-count, maybe it will pass.
2. If it fails at the same block file, delete your database folder and try again. Does it fail at the same block file again during the new scan? It's possible the concurrency issue hit during the build phase and you're seeing the symptoms at the scan phase
3. In general, this is old code I haven't looked at in a while. If this problem persist, I'd invite you to try out the new code in the dev branch, as that's stuff I can realistically debug and fix.
