Maybe drop the number of peers down to 5-7 for now.
I have to say that I was using more bpytop, and just recently (a couple of months ago) switched to btop. However, I have never had any problems with it. It was always rock solid. Also, you are running ARM version, so maybe that build is not that well tested. Assuming that it shouldnât be crashing, maybe this indicated a low RAM situation? Have you tried to go through system logs, maybe you could find something there? Also, maybe try to create a swap file on your SSD.
That second log has an Exception there. That is not a normal behavior, but not diving deeper into the code it is hard to tell whether just that one connection task was taken down, or rather from that point on chia got unstable. My take is that in the production code there should be no Exceptions, but chia has it all over the place, making it harder to understand how critical those are.
Banning peers is normal, so I would not worry about it (yet, see below). Although, the next block couples peer-banning with those peers being on a different network (not sure whether a testnet (no clue how it could be) or a forked branch). I have not seen those before but would think that those should be rather rare things, and not happening to a bunch of peers roughly at the same time.
My understanding is that a node cannot tell whether it is on the main chain or on the forked one. The node assumes that the main chain is the one that majority of peers agree with. What it means is that potentially your node got on a forked chain. I donât know whether the node can recover by itself from being on a forked branch, or what to do to bring it back to the main chain.
From the node perspective, it is enough to have just 1 peer, as long as the peer is reliable. This setup is mostly used for a secondary (backup) node at home (kind of crude master/slave). Maybe just for testing, you could sync to just 1 or 2 peers for a couple of days. In config.yaml there should be an option to specify trusted peers and those take preference over other peers. Unfortunately, I am not running my chia node at the moment (I run a test one, but it is spotty). Maybe a couple of folks could PM you and provide their IPs to link to (they need to have port 8444 open, though).
As far as that chia show -s, just grep for âSyncedâ and only logs those times.
As far as monitoring / logging your box, I use node-exporter / prometheus / grafana to do that. You would run node-exporter on your RPi and prometheus / grafana on another box. Here is a link about running it on RPi - Prometheus node exporter on Raspberry Pi - How to install - Linuxhit (I didnât read it, though). Again, you donât want to run prometheus / grafana on your RPi to not introduce extra stress thus further obscure the problem.
Nothing really stands out from what you have there. That btop crashing may suggest low RAM and that last block being forked out (although, I donât know how to explain that you are forked out so often - maybe remove that peers db, as that is the starting point for a new start).
Maybe the first thing to do would be to add that swap file and drop peer count to 5. If that leads nowhere, to try to get a couple of reliable / trusted nodes and drop count to 1-2. Also, maybe run fsck on the SSD, if you didnât already. By the way, is your OS on the same SSD as chia, or on an SD card (I would move it to an SD card)?
Lastly, I would create a ticket on btop github (Issues ¡ aristocratos/btop ¡ GitHub) about that crash. Maybe someone will comment what the most likely reason could be for it (basically pointing you in a right direction with your chia / RPi setup).
UPDATE:
I have started my (Win) node and was looking at logs. Actually, there are not that many lines being pumped right now on INFO level (maybe a couple per second), where the old dust storms were pushing multiple lines per millisecond. Therefore, ignore all my previous whining about those logs putting pressure (keep them at INFO and on your SSD). Not sure if logs improved (got trimmed), or this is a different type of dust storm that mainly attacks mempool (keeps pressure on fees).
Also, that box (i5-8250U) runs at about 5% of CPU. This would suggest that your RPi should be able to handle that load. RAM load is at a tad over 7GB total, so maybe close to a borderline for RPi without a swap.
As @JeffJN suggested, maybe v2.1.3 is buggy, or doesnât work that well on ARM / RPi, so maybe upgrade to that v2.1.4-rc version.
