Skip to main content
added 447 characters in body
Source Link
RedGrittyBrick
  • 28.5k
  • 3
  • 25
  • 53

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

You could also use Linux tools to monitor usage of memory and other resources. Maybe vmstat or top would show something interesting. Maybe bitcoind is filling a filesystem you didn't expect - df -Pk.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.

I've had it just stop for no discernable reason.

As well as turning up debug to the max, I would try to capture the return code ($?) of bitcoind.

If i want to make sure my node is up... what's the best way to do that?

The daemon process startup system on your Linux distro ought to be able to auto-restart a stopped daemon. You configure the startup system appropriately. Details probably depend in distro and version. E.g. in systemd: restart=always

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.

I've had it just stop for no discernable reason.

As well as turning up debug to the max, I would try to capture the return code ($?) of bitcoind.

If i want to make sure my node is up... what's the best way to do that?

The daemon process startup system on your Linux distro ought to be able to auto-restart a stopped daemon. You configure the startup system appropriately. Details probably depend in distro and version. E.g. in systemd: restart=always

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

You could also use Linux tools to monitor usage of memory and other resources. Maybe vmstat or top would show something interesting. Maybe bitcoind is filling a filesystem you didn't expect - df -Pk.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.

I've had it just stop for no discernable reason.

As well as turning up debug to the max, I would try to capture the return code ($?) of bitcoind.

If i want to make sure my node is up... what's the best way to do that?

The daemon process startup system on your Linux distro ought to be able to auto-restart a stopped daemon. You configure the startup system appropriately. Details probably depend in distro and version. E.g. in systemd: restart=always

added 447 characters in body
Source Link
RedGrittyBrick
  • 28.5k
  • 3
  • 25
  • 53

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.

I've had it just stop for no discernable reason.

As well as turning up debug to the max, I would try to capture the return code ($?) of bitcoind.

If i want to make sure my node is up... what's the best way to do that?

The daemon process startup system on your Linux distro ought to be able to auto-restart a stopped daemon. You configure the startup system appropriately. Details probably depend in distro and version. E.g. in systemd: restart=always

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.

I've had it just stop for no discernable reason.

As well as turning up debug to the max, I would try to capture the return code ($?) of bitcoind.

If i want to make sure my node is up... what's the best way to do that?

The daemon process startup system on your Linux distro ought to be able to auto-restart a stopped daemon. You configure the startup system appropriately. Details probably depend in distro and version. E.g. in systemd: restart=always

Source Link
RedGrittyBrick
  • 28.5k
  • 3
  • 25
  • 53

What's the best way to troubleshoot the stability of bitcoind?

I would say logging.

The debug.log doesn't show anything particularly interesting.

If you are not already running bitcoind with option -debug=1, I suggest you try it.

-debug=<category>

Output debugging information (default: -nodebug, supplying <category> is 
optional). If <category> is not supplied or if <category> = 1, output all 
debugging information. <category> can be: net, tor, mempool, http, bench, 
zmq, walletdb, rpc, estimatefee, addrman, selectcoins, reindex, cmpctblock, 
rand, prune, proxy, mempoolrej, libevent, coindb, qt, leveldb, validation.

Note that the default is -nodebug.