Pose banned and rewards
- Thread starter Rul
- Start date
qwizzie
Well-known member
Take a look at the recommended requirements and see if your masternode hardware is sufficient.
Link : https://docs.dash.org/en/stable/masternodes/understanding.html#masternode-requirements
With PoSe bans you not only need to issue a protx update_service command to get your masternode released from its PoSe ban , you also need to fix the reason why your masternode got PoSe banned in the first place. Or you run the risk that this will happen again... and again.. and again.
You need to check if you have enough diskspace, enough RAM, installed enough SWAP space, have sufficient CPU power and have a restart script or command active on dashd (for example : * * * * * pidof dashd || ~/.dashcore/dashd in your crontab)
Also check this checklist : https://docs.dash.org/en/stable/masternodes/maintenance.html#proof-of-service-bans
You can also take a look at your debug.log .. to see if there is some error mentioned there.
When you do issue a protx update_service command (to get your masternode released from its PoSe ban), i would monitor the RAM usage for awhile. Which means logging into your masternode server from to time and monitor its RAM usage, maybe check your masternode server hardware statistics over time as well.
Also it could be handy to keep an eye on dashd.pid .. note when you first started it and when it was last changed (restarted again). When you have a lot of changed dashd.pid over time with a much more recent date, then that indicates a lot of dashd restarts. Which should not happen all that often on a good functioning masternode.
Link : https://docs.dash.org/en/stable/masternodes/understanding.html#masternode-requirements
With PoSe bans you not only need to issue a protx update_service command to get your masternode released from its PoSe ban , you also need to fix the reason why your masternode got PoSe banned in the first place. Or you run the risk that this will happen again... and again.. and again.
You need to check if you have enough diskspace, enough RAM, installed enough SWAP space, have sufficient CPU power and have a restart script or command active on dashd (for example : * * * * * pidof dashd || ~/.dashcore/dashd in your crontab)
Also check this checklist : https://docs.dash.org/en/stable/masternodes/maintenance.html#proof-of-service-bans
You can also take a look at your debug.log .. to see if there is some error mentioned there.
When you do issue a protx update_service command (to get your masternode released from its PoSe ban), i would monitor the RAM usage for awhile. Which means logging into your masternode server from to time and monitor its RAM usage, maybe check your masternode server hardware statistics over time as well.
Also it could be handy to keep an eye on dashd.pid .. note when you first started it and when it was last changed (restarted again). When you have a lot of changed dashd.pid over time with a much more recent date, then that indicates a lot of dashd restarts. Which should not happen all that often on a good functioning masternode.
Last edited:
To resolve a POSE ban, the correct command to send is protx update_service ... The reason for POSE ban may be an under powered VPS, however, I have to admit there are bugs in v0.17 that occasionally cause a random score to appear through no fault of your own, the good news is we've found those bugs and fixed them v18 which will be released in one week !
Your choice of VPS provider matters. Some VPS specs look good on paper yet they get far more bans than others whom just about meet the requirements. This could be an OS issue as I have seen extremely reliable uptime on very old linux distros.
There is also the issue that when a PoSe hits, it seems to escalate very quickly, too quickly. I'm hoping this is fixed in v18.
There is also the issue that when a PoSe hits, it seems to escalate very quickly, too quickly. I'm hoping this is fixed in v18.
Thank you for your answer! I will follow your instructions
Thank you for answer! Glad to hear it!