PoSe Banned is BS

europound

europound

Member
ffs
I have a dedicated server
and it keeps PoSE banned
worst bs invented
anybody else is suffering?


Intel® Core™ i7-6700 Quad-Core Skylake incl. Hyper-Threading Technology
32GB RAM, busy 19GB RAM
2 TB HDD
/dev/md2 1.8T 965G 761G 56% /

40 private IPs
minimal DDOS hetzner


root@Ubuntu-1604-xenial-64-minimal ~ # docker exec -it masternode bash
/root/.bashrc: line 100: ./dashd: No such file or directory
* Starting periodic command scheduler cron [ OK ]
dashman version 0.1.28 (7-gd706581) - Sat Sep 21 17:28:28 UTC 2019
gathering info, please wait... DONE!
hostname : e4658ba3ec87
host uptime/load average : 44 days, 3.44 2.68 2.35
dashd bind ip address : xxxxxxxxxxxx
dashd version : 0.14.0.3
dashd up-to-date : YES
dashd running : YES
dashd uptime : 0 days, 0 hours, 16 mins, 24 secs
dashd responding (rpc) : YES
dashd listening (ip) : YES
dashd connecting (peers) : YES
dashd port open : YES
dashd connection count : 12
dashd blocks synced : YES
last block (local dashd) : 1141414
(chainz) : 1141413
(dash.org) : 1141414
(dashwhale) : 1141414
(masternode.me) : 1141412 - no forks detected
dashd current difficulty : 173090658.3685352
masternode registered : NO
masternode visible (local) : YES
masternode visible (ninja) : NO
masternode address : xxxxxxxxx
masternode funding txn : xxxxxxxxxx
masternode queue/count : 0/4949
masternode mnsync state : MASTERNODE_SYNC_FINISHED
masternode network state : POSE_BANNED
masternode last payment : 1.55332 in 1121862 on 08/17/2019 (35 days, 15 hours ago)
masternode balance : 18.656784550
sentinel installed : YES
sentinel tests passed : YES
sentinel crontab enabled : YES
sentinel online : NO
Exiting.
root@e4658ba3ec87:~/dashman# crontab -
^Croot@e4658ba3ec87:~/dashman# crontab -l
* * * * * cd /usr/local/bin/sentinel && venv/bin/python bin/sentinel.py 2>&1 >> sentinel-cron.log
root@e4658ba3ec87:~/dashman# cd /usr/local/bin/sentinel && venv/bin/python bin/sentinel.py
Invalid Masternode Status, cannot continue.
root@e4658ba3ec87:/usr/local/bin/sentinel#
 
Last edited:
https://docs.dash.org/en/stable/masternodes/maintenance.html#proof-of-service-bans

Personally i never experienced a POSE ban or a POSE penalty, but i know from certain posts others have.
By the way : is your sentinel up to date ? Maybe good to check with a git pull inside your sentinel directory
(i'm not sure sentinel online : NO relates to you being POSE banned or because Sentinel is not up to date)

Also this part worries me (but could be related to your POSE ban) :

masternode registered : NO
masternode visible (local) : YES
masternode visible (ninja) : NO

Also make sure you install Dash Central monitoring and restart script, you will need it.
 
Last edited:
Where are the logs?
How could I debug this bs pose ban?


After pose ban strikes I cannot access daemon right?
Mn declines connection?
Masternode connect ip unsuccessful
 
Reinstall it using the guide unless you like wasting time and money, then be my guest.
 
how can docker affect it?
is this version compatible with docker?
before this update dash worked for months and months without an issue
 
I said nothing about Docker, it should work in Docker too although you are wasting RAM/Disk running Docker for a masternode. Debugging your setup would require going through my guide and seeing where you do things differently, I've seen people put `git pull` into crontabs. :( run `dashd` as root :mad: run `sentinel` every minute :eek: have conflicting versions of `dashd` :confused: run a MN that is firewalled :eek: etc etc etc etc.
 
dashd as root will not work?


* * * * * cd /root/.dashcore/sentinel && venv/bin/python bin/sentinel.py 2>&1 $
* * * * * pidof dashd || ~/.dashcore/dashd


and sentiel should be running every minute
and if dashd is not running then start dashd as well



https://docs.dash.org/en/stable/masternodes/setup.html


crontab -e

Choose nano as your editor and enter the following lines at the end of the file:

* * * * * cd ~/.dashcore/sentinel && ./venv/bin/python bin/sentinel.py 2>&1 >> sentinel-cron.log
* * * * * pidof dashd || ~/.dashcore/dashd

Press enter to make sure there is a blank line at the end of the file, then press Ctrl + X to close the editor and Y and Enter save the file. We now need to wait for 15 confirmations of the collateral transaction to complete, and wait for the blockchain to finish synchronizing on the masternode. You can use the following commands to monitor progress:

~/.dashcore/dash-cli mnsync status
 
I have seen issues with low speced machines running `sentinel` every minute, I run it every 10 minutes `*/10 * * * *` and never had a problem. If you have cycles to burn go for it, but when I looked at the code I could see that `sentinel` is not required to run that frequently, even 10 minutes is overkill. Are there material advatanges to running it more frequently, if so, would it be better to run it every 30 seconds?
 
xkcd said:
I have seen issues with low speced machines running `sentinel` every minute, I run it every 10 minutes `*/10 * * * *` and never had a problem. If you have cycles to burn go for it, but when I looked at the code I could see that `sentinel` is not required to run that frequently, even 10 minutes is overkill. Are there material advatanges to running it more frequently, if so, would it be better to run it every 30 seconds?
Click to expand...

Low-spec machines that can't handle running sentinel every minute should probably not be MNs.

That said, the reason this is done every minute is historical. Not running it used to cause MNs to get kicked from the queue. Internally there's a sleep which was to prevent network traffic spikes if all MNs ran it and generated traffic at the same time (e.g. watchdogs). Back then, it wasn't every minute, but something like every 10 minutes. I can't remember exactly, but the point is that since clocks are synced and cron would schedule it then it would send a lot of traffic all at once, so a sleep was put in. There's also a lock which prevents Sentinel from running over itself (e.g. only one copy of the process will be running at a time). Currently there are no watchdogs (they were removed a couple years ago) and penalties for not running Sentinel aren't enforced as this caused more issues than not. To answer your question, there are no advantages to running Sentinel more frequently.

Running Sentinel today does 2 things: some voting to remove old gov objects and it votes on the monthly Superblock. If a few people stopped running it I don't think it would affect anything (their MNs shouldn't go down AFAIK). If everyone did, we might have problems with SBs and old object cleanup. Of course if we move to on-chain governance then this is all moot as Proposals and Votes could be transactions on-chain. Sentinel would go away entirely.
 
Thanks Nathan for your reply, I would LOVE to see Sentinel go away entirely as I see it as a technical kludge, but since my MN runs just fine with the service being invoked every 10 minutes I will keep it at that for the present time. I do agree that MNOs should over provision their setups, but what I see in the wild is contrary to that and I do believe MNOs are more price sensitive than they ought to be, ie picking out the cheapest VPS possible.

Slightly off topic, but the DIP 3 activation should us that MNOs are happy to sell when we increase the friction on them, to date many of the nodes prior never came back, the DASH was de-collateralised and sold rather than going through the 3-step tango that the rest of us did, if for some reason every MNO had to upgrade their specs tomorrow due to a new release, I am certain another wave of MNs would go offline too, it's not rational, but this enitre industry is irrational so at least it's consistent.
 
You must log in or register to reply here.
Back
Top