BitShares Forum
Other => Graveyard => MemoryCoin => Topic started by: Tamis on December 17, 2013, 04:21:25 pm
-
Hi,
as explained by many on bitcointalk forum the linux miner (https://github.com/memorycoin/memorycoin) is crashing in several ways.
Sometimes it is just the daemon that need to be restarted sometimes the whole .memorycoin folder needs to be deleted.
Anyone working on this ?
edit :
It's been a few hours since i've asked this really important question !
now correct me if i'm wrong (I could really be on this) but isn't someone paid to take care of answering and all ? If so he's not doing his work !
-
Noone is being paid.
I'm alone here to support all questions, please be patient.
The problems are known and FreeTrade is working on it.
He made a thread about this, you can find it here: https://bitsharestalk.org/index.php?topic=1447.0
-
This does not address the problem i'm talking about !
The fork is to fix the difficulty adjustement not the crash of the linux miner...
-
So I think the Linux crashes, database/wallet corruption issues all stem from the same cause - a memory leak.
It almost certainly occurs in the momentum.cpp code, and might be a memory leak in the opensll lib's AES routine for some platforms. I don't know yet - I'm trying to track it down.
I'm gathering information for it here -
If you're getting a crash on linux, it would be useful to know what platform you're on, what version of openssl you're using, how many threads you're running and how many cores you have.
-
I get the crashes regularly on Ubuntu 13.10 x64. 32 Cores (Xeon) with 64 GB RAM. Sometimes it's enough to restart daemon, sometimes bitcoind -resync helps, sometimes only a deletion of database.
When the database corruption occurs and I restart with bitcoind -resync I get this:
Do you want to rebuild the block database now?
bitcoind: db/version_set.cc:715: leveldb::VersionSet::~VersionSet(): Assertion `dummy_versions_.next_ == &dummy_versions_' failed.
If I answer with
y
I get
y: command not found
so have to delete the database manually.
---
ubuntu@ip-172-31-18-71:~$ apt-file search libssl.so
libssl-dev: /usr/lib/x86_64-linux-gnu/libssl.so
libssl0.9.8: /lib/x86_64-linux-gnu/libssl.so.0.9.8
libssl0.9.8: /usr/lib/x86_64-linux-gnu/libssl.so.0.9.8
libssl0.9.8-dbg: /usr/lib/debug/lib/x86_64-linux-gnu/libssl.so.0.9.8
libssl1.0.0: /lib/x86_64-linux-gnu/libssl.so.1.0.0
libssl1.0.0-dbg: /usr/lib/debug/lib/x86_64-linux-gnu/libssl.so.1.0.0
--
before compiling installed libssl this way:
apt-get install -y libssl-dev
p.s.
Solving a difficult captcha before posting is extremely annoying! I bet 90% users do not post because of this.
-
My "temporary" solution:
crontab script
nano /opt/memorycoin.sh
#!/bin/bash
APP_NAME=bitcoind
LISTEN=1925
INIT_SCRIPT="/root/memorycoin/src/bitcoind"
CONFIG_DIR="/root/.memorycoin/"
PID=`ps ax |grep "$APP_NAME --daemon" |grep -v grep |awk '{print $1}'`
ENABLED=1
TIMEOUT=30
test "$ENABLED" != "0" || exit 0
function testnetcat() {
/bin/netcat -w 10 -z 127.0.0.1 $LISTEN
}
if [ "x$PID" == "x" ]
then
$INIT_SCRIPT --daemon
exit $RETVAL
else
testnetcat
RETVAL=$?
if [ "$RETVAL" == "0" ]
then
exit $RETVAL
else
sleep $TIMEOUT
testnetcat
RETVAL=$?
if [ "$RETVAL" == "0" ]
then
exit $RETVAL
else
killall -9 $PID
sleep 5
rm -rf $CONFIG_DIR/blocks
rm -rf $CONFIG_DIR/chainstate
rm -rf $CONFIG_DIR/database
rm -rf $CONFIG_DIR/*log
rm -rf $CONFIG_DIR/.lock
rm -rf $CONFIG_DIR/*pid
$INIT_SCRIPT --daemon
exit $RETVAL
fi
fi
fi
chmod 755 /opt/memorycoin.sh
crontab -e
*/5 * * * * /opt/memorycoin.sh
and repair.sh
#!/bin/bash
APP_NAME=bitcoind
LISTEN=1925
INIT_SCRIPT="/root/memorycoin/src/bitcoind"
CONFIG_DIR="/root/.memorycoin/"
PID=`ps ax |grep "$APP_NAME --daemon" |grep -v grep |awk '{print $1}'`
ENABLED=1
TIMEOUT=30
test "$ENABLED" != "0" || exit 0
killall -9 $PID
sleep 5
rm -rf $CONFIG_DIR/blocks
rm -rf $CONFIG_DIR/chainstate
rm -rf $CONFIG_DIR/database
rm -rf $CONFIG_DIR/*log
rm -rf $CONFIG_DIR/.lock
rm -rf $CONFIG_DIR/*pid
$INIT_SCRIPT --daemon
for standalone/manual repair after crash.
-
I'm 99% sure I've found the solution to prevent all the crashes that happen on linux.
For two days the client crashed regularly. After my fix not a single crash or database corruption in 8 hours!!
The crash and database damage happen only if the client is run more than once at the same time.
Now you may ask, why run the client a second time?
A lot of people do it, to read the status from the client, meaning ...
a script starts bitcoind --daemon
but then either another script, cron, or manual command line is used in this way:
watch 'bitcoind getmininginfo & bitcoind listaccounts'
and this watch command calls bitcoind every two seconds, and there is a small chance that the daemon will crash. or it's caused by a memory leak, but not by the deamon, but by the getmininginfo call performed every 2 seconds!
I've disabled my watch script on all 5 linux instances, did no other chances whatsoever (besides a reset to make sure the damage done by watch/getmininginfo is gone), and after 2 days full of crashes, not a single memorycoin daemon crash, in over 8 hours of mining!
I hope this helps.
-
Running memorycoind without the watch scripts and the latest source from github.
The memory leak was not apparent for the first few minutes of running, it was sitting at about 10 GB virtual memory per thread.
Then suddenly it shot up to 16 GB of virtual memory per thread.
Overall, why do the threads use such a small amount of real memory, if this is supposed to be "memory coin". It looks like this is a fork from protoshares, and in protoshares each thread was using roughly 512 Mb of memory. Here we have each thread only using 34MB of memory.
Something still seems wrong here.
-
I'm 99% sure I've found the solution to prevent all the crashes that happen on linux.
For two days the client crashed regularly. After my fix not a single crash or database corruption in 8 hours!!
The crash and database damage happen only if the client is run more than once at the same time.
Now you may ask, why run the client a second time?
A lot of people do it, to read the status from the client, meaning ...
a script starts bitcoind --daemon
but then either another scrypt, cron, or manual command line is used in this way:
watch 'bitcoind getmininginfo & bitcoind listaccounts'
and this watch command calls bitcoind every two seconds, and there is a small chance that the daemon will crash. or it's caused by a memory leak, but not by the deamon, but by the getmininginfo call performed every 2 seconds!
I've disabled my watch script on all 5 linux instances, did no other chances whatsoever (besides a reset to make sure the damage done by watch/getmininginfo is gone), and after 2 days full of crashes, not a single memorycoin daemon crash, in over 8 hours of mining!
I hope this helps.
Thanks for the tip! Do you have a MC address for tips?
-
Running memorycoind without the watch scripts and the latest source from github.
The memory leak was not apparent for the first few minutes of running, it was sitting at about 10 GB virtual memory per thread.
Then suddenly it shot up to 16 GB of virtual memory per thread.
Overall, why do the threads use such a small amount of real memory, if this is supposed to be "memory coin". It looks like this is a fork from protoshares, and in protoshares each thread was using roughly 512 Mb of memory. Here we have each thread only using 34MB of memory.
Something still seems wrong here.
The MemoryCoin miner requires 1GB and all the threads access that memory. You could write a miner that uses more memory - you might get slightly better results from it if you have multiple memory chips in the computer.
-
Thanks for the tip! Do you have a MC address for tips?
MLbH5YtCB73CYN375EMMfywN18emFPjDxm
thank you very much!
-
Thanks 200MMC on its way to you.
-
crendore how do you check balance or transactions now? I'm getting RPC command lock-ups especially when database is checked on startup or vote is happening. Sometimes there is a second process like "memorycoind getbalance" waiting for the main thread that never finishes. Any ideas?
-
crendore how do you check balance or transactions now? I'm getting RPC command lock-ups especially when database is checked on startup or vote is happening. Sometimes there is a second process like "memorycoind getbalance" waiting for the main thread that never finishes. Any ideas?
in memoricoind:
memorycoind getaccountaddress ""
<address>
memorycoind dumpprivkey <address>
<privkey>
In memorycoin-qt:
importprivkey <privkey> label true
restart memorycoin-qt
When memorycoind will be find block, in memorycoin-qt this will instantly appear.
-
Looks like I'm wrong.
memorycoind getaccountaddress ""
creates a new wallet.
-
Get your address is correct so:
memorycoind listreceivedbyaddress 1 true
-
Has the linux client finally been fixed ?
I gave up some time ago because of this...