V12 Release

MangledBlue said:
This doesn't fix the crash issues?
Click to expand...

The crash issues you are having aren't very common.
I run dashd on a vps with 256M of ram (with 1G of swap) and have no crashes whatsoever, so the issue isn't your ram.

It may be environmental too, radio noise from neighboring electronics could cause trouble, it's an unshielded board. Are there any computers near it? Try moving it further from any other computers/tvs/radios/etc. If it stops crashing, you *may* want to get yourself a metal case for it, but confirm before spending any money on it.

Also, make sure your pi has plenty of power. Are you overclocking it? If so, does it have a heat sink? Does your adapter deliver 2.5 watts needed for 1GHz clocking with voltages set above 1? Are you overclocking without bumping up the voltage?

Does your sd-card have any corrupted sectors? Have you done a fsck lately? Did you verify the card was good by doing read/write benchmarks on it before installing on it? Is it a fast sd card like one of these? http://www.amazon.com/gp/product/B00M55C0NS

There's a lot of things to check, for sure.

Try running the latest pi build (don't build it yourself) https://dashpay.atlassian.net/build...gitian-RPi2-dash-dist/dash-0.12.0-RPi2.tar.gz and see if you have better luck.

.55 cpu and network usage is about half of .53 it may make the difference.

Or the issue is somewhere else like I mentioned.
 
Last edited by a moderator:
I think I had a similar problem that camosoul had with updating. I updated all my nodes to .55. A few of them didn't stay active. They were running and on the right block, but they fell off the list. Every time I tried to start with the local wallet it crashed. It just locked up no response. I had to shut server nodes down for a few minutes. Then start up and start-alias from local wallet to get them going. I have a 40 second wait between shutdown of old node and start of new version. I will try a bump up to 120 seconds on the next release to see if that fixes it.
 
moocowmoo said:
.55 cpu and network usage is about half of .53 it may make the difference.
Click to expand...

We are also seeing a nice drop in cpu since upgrading all nodes to .55. Memory consumption however is seeing just the slightest uptick. Nothing to be concerned about, but thought I'd note it in case others are seeing the same.
 
Sub-Ether said:
I have a crash exit on a windows remote after ~ 3 days, is this update going to make any difference or should I try to workaround it with an auto start loop?
Click to expand...

I was informed there is less computing/RAM "requirements" in this version - From the sound of it, it just might be enough to stop the crashing but only time will tell....

The crons I tried don't help

like:

@rebot dashd
(the crash does not case reboot of the entire system <--- does no good >

and
dashd to reboot every 24 hours at 1am - also did ZERO good
(if the dashd crashes at noon and the reboot is 13 hours away, you're already off the list)

I think I even tried another one.....I had like 3 different crons running

moocowmoo (or was it fuzzyduck? I forgot, sorry) script that looks for the dashd.pid file and runs under 'screen'
- also did no good


I know it's not overheating, I was solo-mining a single core 24/7 @ 1800Hash/s or 1.8KHash/s, on V11 - everything went down-hill with 12

I just can't find anything that points to a/the smoking gun of WHY it's crashing...

Let's see what V55 does I guess....
 
MangledBlue have you tried UdjinM6's script?

run:
Code: 
crontab -e

add line:
Code: 
*/1 * * * * /home/dashuser/mn_watch.sh >/dev/null 2>&1

use any editor you like and save this as "mn_watch.sh" file in user "dashuser" home directory:
Code: 
#!/bin/bash
if [ -z `pidof dashd` ]; then
/home/dashuser/dashd
fi

add executable flag:
Code: 
chmod u+x mn_watch.sh

Use appropriate username, not "dashuser" from my example
wink.gif

I also assumed that dashd is located in your user home directory, change path if needed.
 
eduffield said:
V0.12.0.55 Is Out!

- Huge Chinese/Japanese Update
- gettransaction now works with IX
- fix LP inter-mixing by not initiating new queues by them (Udjin)
- Support for trustless proposal voting (DashWhale)
- SK translation
- DS - try to use inputs with the same number of rounds (Udjin)
- GetRemainingPaymentCount was off by one

https://www.dashpay.io/downloads/
Click to expand...

Recently discovered that shapeshift.io ignores IX TXes, even after they appear in the chain. Maybe the above highlighted is related?
 
ErrorId said:
MangledBlue have you tried UdjinM6's script?

run:
Code: 
crontab -e

add line:
Code: 
*/1 * * * * /home/dashuser/mn_watch.sh >/dev/null 2>&1

use any editor you like and save this as "mn_watch.sh" file in user "dashuser" home directory:
Code: 
#!/bin/bash
if [ -z `pidof dashd` ]; then
/home/dashuser/dashd
fi

add executable flag:
Code: 
chmod u+x mn_watch.sh

Use appropriate username, not "dashuser" from my example
wink.gif

I also assumed that dashd is located in your user home directory, change path if needed.
Click to expand...
Keep in mind this only works once. On the 2nd crash the dashd will have a different process id, so this will continuously try to start dashd every minute. Dashd will check if it is running, so that isn't bad, but I think 1 minute is too fast for the Pi to figure all this out. You would be better off to just do a crontab (runs every 10 minutes) that has:
*/10 * * * * /home/dashuser/dashd
 
Solarminer said:
*/10 * * * * /home/dashuser/dashd
Click to expand...
Solarminer Thanks! That's even simpler. Since dashd is already running the new process will not be able to get a lock on the data directory and will shut down or in case of a crash will launch.

Now the only thing I need to figure out is how to handle a frozen daemon.
 
Last edited by a moderator:
eduffield said:
- fix LP inter-mixing by not initiating new queues by them (Udjin)
Click to expand...
The genius that makes you say "holy crap, that's so simple!"

Take apart an expensive gun and you find a swiss-watch-like machine that'll never work outside of a laboratory-like gun range. They're always breaking. It's the cheap beaters that impress with simple genius. AK-47. M11. PPS-41 (The PPS-41 was actually designed and manufactured as the Nazis were bombarding the building it was being made in. The soldiers defending the building picked the guns up right off the assembly line and managed to hold. The Russians then went on to produce more of the PPS-41 than any other gun in WWII. Talk about performance under pressure! Had they failed in this production and subsequent application of the PPS-41, WWII would have been lost by the allies. Did they teach you that bit of history in school? This gun is the reason the free world still exists, it was designed and made just in the nick of time, and it's not American. To think the tiny little things that could have gone differently, the incredible timing, and we have the Russians to thank for it.).

There are examples of PPS-41s with over 1,000,000 rounds through them. All original parts. Nothing broke. Glock perfection my ass... Then again, open-bolt, fixed-pin sub-machineguns are sledge-hammer simple. That's the real reason they're banned... If you knew how easy it is to make one, you'd laugh at the idea of gun control. So, ban them, and you ban the understanding along with it. then you can tell any lie you want.

The gun snobs call them crap. But they never break, and always go bang... This is the genius of simple solutions. It saved the entire free world once, just barely. And here's Udjin, at it again... ;-)
 
Last edited by a moderator:
Solarminer said:
Keep in mind this only works once. On the 2nd crash the dashd will have a different process id, so this will continuously try to start dashd every minute. Dashd will check if it is running, so that isn't bad, but I think 1 minute is too fast for the Pi to figure all this out. You would be better off to just do a crontab (runs every 10 minutes) that has:
*/10 * * * * /home/dashuser/dashd
Click to expand...
The Pi is a quad core 1GHz CPU. I'm pretty sure it can handle it...

I was running Gentoo before there was 64 bit... Hell, before there was Athlon... cron existed in the 1970s, mmm Sun Sparc... I still have one.
 
Last edited by a moderator:
Solarminer said:
Keep in mind this only works once. On the 2nd crash the dashd will have a different process id, so this will continuously try to start dashd every minute. Dashd will check if it is running, so that isn't bad, but I think 1 minute is too fast for the Pi to figure all this out. You would be better off to just do a crontab (runs every 10 minutes) that has:
*/10 * * * * /home/dashuser/dashd
Click to expand...

That's incorrect, that's now how pidof works.
 
camosoul said:
The Pi is a quad core 1GHz CPU. I'm pretty sure it can handle it...

I was running Gentoo before there was 64 bit... Hell, before there was Athlon... cron existed in the 1970s, mmm Sun Sparq... I still have one.
Click to expand...
The Pi is running from an SD card. It takes dashd about 10 seconds to figure out it is running on my servers and return a message. SD card would slow that up quite a bit.
 
Solarminer said:
Thanks Moocowmoo, I just learned something. I was interpreting "pidof dashd" to replace with the actual process id.
Click to expand...
You're welcome. The backticks `` are a bash-style command substitution. Using $() is more portable, but I still have the backtick habit too.
 
ErrorId said:
Solarminer Thanks! That's even simpler. Since dashd is already running the new process will not be able to get a lock on the data directory and will shut down or in case of a crash will launch.

Now the only thing I need to figure out is how to handle a frozen daemon.
Click to expand...
Check my bitcointalk post a week or two back. I put a script that checks for blocks and if no block is found in 30 minutes shuts down and restarts. This really doesn't happen though. Dashwhale also has a monitor that will do that too and email notifications.

Usually, dashd crashes because of a ram limitation. Of course, MangledBlue's pi has other issues - light sensitivity, allergies, etc.
 
Solarminer said:
The Pi is running from an SD card. It takes dashd about 10 seconds to figure out it is running on my servers and return a message. SD card would slow that up quite a bit.
Click to expand...
Eh, depends on the uSDcard. I have an expensive fast one, and it nips at the heels of my SSD in read/write. If you have a cheap slow one, then you very well could experience that latency.
 
Solarminer said:
Check my bitcointalk post a week or two back. I put a script that checks for blocks and if no block is found in 30 minutes shuts down and restarts. This really doesn't happen though. Dashwhale also has a monitor that will do that too and email notifications.

Usually, dashd crashes because of a ram limitation. Of course, MangledBlue's pi has other issues - light sensitivity, allergies, etc.
Click to expand...


All Pi's have light issues.... allergies pffft..lol
 
You must log in or register to reply here.
Back
Top