Search results

I fixed the issue by reinstalling sentinel. However Ninja is showing my node as offline.

Guys please help!!! My Ninja status is showing as inactive now!!! All of this happened after I upgraded to Ubuntu 17.10. Can someone please explain what I should?

I am now getting the below error : Can you tell me why? My node is also showing as inactive on Ninja! sentinel tests passed : /root/dashman/lib/dashman_functions.sh: line 1129: [: too many arguments NO sentinel crontab enabled : YES sentinel online : NO

I am now seeing this error when I call on Dashman status under "Sentinel Tests Passed" : /root/dashman/lib/dashman_functions.sh: line 1129: [: too many arguments NO How can I fix this?

Too late. I already restarted my MNs to err on the side of caution. This is the 2nd time in which Dashman was reflecting a different Ninja status than the Ninja site itself (the 1st was when that project with incorrect comma was inserted). All my MNs were showing enabled and counting down...

Yes, take it from me. I've lost countless Dash because I didn't upgrade to 1gb ram. Its not worth the risk.

I checked Dashman and the MNs network state is "enabled" and they are counting down, but my wallet status shows "Upgrade". Guys, I need your help to figure out whether to wait per the Dashman status or upgrade immediately.

How do you download the latest version if you are hosting with Ubuntu?

All my Masternode Status's are blaring red now with "Upgrade". However, when I check on the status using Dashman, their network state shows "enabled" and they are counting down. My question is does this status mean I need to perform the upgrade immediately or can I wait until they get paid...

By when do we need to upgrade our masternodes to 12.2?

By when do we need to update our Masternodes to 12.2?

I appreciate the help guys, but its already too late since the start command reset my node and I lost out on 1.5 cycles thanks to this flawed proposal. On another note, we can't allow a comma to bring the whole network down and this is something that I hope the Dash devs are looking to prevent.

I had a very interesting situation happen which may a highlight a serious flaw. After 10/26, one of my masternodes showed as "inactive" on Ninja. However, when checking the status on Dashman, it reflected the network state as "enabled" , visible to ninja, and was counting down to payment...

It's already too late. I typed the "masternode start missing" command thinking that it would just make my node reappear on ninja but it actually sent it back to the beginning of the cue which is a piss off because I lost out on 1.5 cycles (my place was indicated as 4/4500 to get paid when I did...

I went ahead and restarted the MN from the wallet and I got reset back all the way to the beginning of the payment cue. Quite pissed about this.

It does show "New Start Required". If I do start missing from my wallet, this will reset my place in the payment cue which I'm trying to avoid. My dashman status still shows the Masternode as Enabled and is counting down to payment. I'm currently at 8/4579. Can someone explain this...

Hi, As the title suggests, my masternode has been showing an inactive status on Ninja as well as in my Dash wallet for almost a week now. However, when I check the status on Dashman, it shows the masternode status as "Enabled" and the selection counting down (with a "selection pending"...

I've actually figured out a way to upgrade the VULTR servers to get more RAM, but it required a reset. Will I lose my place if I perform the upgrade and reset the server immediately and restart Dashman? I recall there is a 2 hour window, but just want to make sure.

I've been using old VulTR servers with 756 MB ram and getting fed up with the constant outages (which causes me to miss payments). What is the best way to move my masternodes to a better server with a different IP and without disrupting its turn in the cue?

My masternodes have been running fine for the past couple of months. Recently however, they keep shutting down and I have to go in and keep restarting them. Is there a reason why this is happening? I had a similar issue months ago and what seemed to resolve it is expanding the virtual...