Author Topic: Linux miner crashing on regular basis  (Read 8195 times)

0 Members and 1 Guest are viewing this topic.

Offline Tamis

  • Newbie
  • *
  • Posts: 3
    • View Profile
Has the linux client finally been fixed ?

I gave up some time ago because of this...

Offline agran

  • Full Member
  • ***
  • Posts: 93
    • View Profile
Get your address is correct so:

memorycoind listreceivedbyaddress 1 true
MMC: MEKdGj95hNjuYn8xiw4iz1iQUQGA47UBMB | BTC: 1agran1xQ4Nwiqv1qegBDF6kqZdfESMUG

Offline agran

  • Full Member
  • ***
  • Posts: 93
    • View Profile
Looks like I'm wrong.
memorycoind getaccountaddress ""
creates a new wallet.
MMC: MEKdGj95hNjuYn8xiw4iz1iQUQGA47UBMB | BTC: 1agran1xQ4Nwiqv1qegBDF6kqZdfESMUG

Offline agran

  • Full Member
  • ***
  • Posts: 93
    • View Profile
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.


« Last Edit: December 22, 2013, 11:13:15 pm by agran »
MMC: MEKdGj95hNjuYn8xiw4iz1iQUQGA47UBMB | BTC: 1agran1xQ4Nwiqv1qegBDF6kqZdfESMUG

Offline h0g0f0g0

  • Jr. Member
  • **
  • Posts: 48
    • View Profile
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?

Offline FreeTrade

  • Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
Thanks 200MMC on its way to you.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline Shadow

  • Newbie
  • *
  • Posts: 4
    • View Profile
Thanks for the tip! Do you have a MC address for tips?

MLbH5YtCB73CYN375EMMfywN18emFPjDxm

thank you very much!

Offline FreeTrade

  • Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
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.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline FreeTrade

  • Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
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?
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline crendore

  • Jr. Member
  • **
  • Posts: 48
    • View Profile
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.

Offline Shadow

  • Newbie
  • *
  • Posts: 4
    • View Profile
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.
« Last Edit: December 21, 2013, 02:31:30 am by Shadow »

Offline delta123

  • Jr. Member
  • **
  • Posts: 25
    • View Profile
My "temporary" solution:

crontab script
Code: [Select]
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
Code: [Select]
#!/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.





Offline Shadow

  • Newbie
  • *
  • Posts: 4
    • View Profile
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.

Offline FreeTrade

  • Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
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.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline Tamis

  • Newbie
  • *
  • Posts: 3
    • View Profile
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...