You can use logrotate.
Create a file named bitcoin-debug in /etc/logrotate.d.
This is the contents:
kill -HUP `cat /home/bitcoin/.bitcoin/bitcoind.pid`
If some client's actions do not correspond with the Bitcoin protocol in a disruptive manner (e.g. flooding with invalid messages) a ban counter is increased depending on the seriousness of the violation of the protocol. When the ban meter reaches some predefined value (can be set with the -banscore option in bitcoind, default is 100) connection to that ...
LogPrint and LogPrintf are very similar.
Mind the definiton: #define LogPrintf(...) LogPrint(NULL, __VA_ARGS__)
LogPrint's will only end up in your debug.log when enabling the corresponding category. Enabling works over the -debug arg.
-debug=mempool,net would output all LogPrint("mempool",...) or LogPrint("net",...) to the debug log, or to stdout if -...
If you look in debug.log, you should see a message that says "proof-of-work found".
Here is an excerpt from debug.log for a testnet block that I found. (It was immediately orphaned; in fact an earlier block had been found several minutes earlier but had not yet reached me. So you won't find it in the blockchain.)
Not only can you write such a program, you probably already have one. If you run the standard Bitcoin Core client, you will see that debug.log logs the IP addresses of every network node it communicates with. (It's irrelevant whether you use the client for mining or not - even non-mining nodes need to connect to peers, and could keep track of which peers ...
If you run the daemon or the GUI (bitcoin-qt) using the debug=1 argument, then bitcoin will write a variety of events to the debug.log file, including info about transactions received by your node.
I just ran a test to confirm this. You could follow these steps if you want:
(1) From the terminal window, start bitcoin-qt like this: $bitcoin-qt -debug=1
That sounds like it's going out of memory and is killed by the system. Especially on a low-memory device like an RPi3 this seems very likely.
For information on how to reduce bitcoind memory usage, see https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-memory.md
Ok, I found the problem.
The thing is that you can not start mining prior to synchronizing with the network (getting all the blocks). The client is not telling you this and tells you that it is mining, when in fact it does not.
So there is no point in clicking start mining before you got everything. After you got all the blocks and pressing mining you can ...
The latest bitcoin source doesn't output any debug log in chainparams.cpp.
Use GenesisH0 to find your Genesis block hash.
make && sudo make install
Run it again, then you will see debug.log within your bitcoin folder
First, I want to make sure that a sufficient number of lightweight wallets are connected to the node.
There's very little use of BIP37 today, and it's not even served by default by modern versions of Bitcoin Core. The chance that anybody would even connect to you and supply filters to you is extremely low. It was always a terrible idea to begin with, giving ...
It's possible that your pool is doing something similar to P2Pool:
Q: Why does my miner say it has found a lot of shares but p2pool say I
have only found a few?!
A: The real P2Pool difficulty is hundreds of
times higher than on normal pools, but p2pool essentially lies to your
miner and tells it to work on relatively easy shares so that it
As I don't have enough reputation to add a comment to hsmiths (correct!) answer above:
I found I had to also add a line to tell logrotate to switch users to the bitcoin user (as I run bitcoind as its own user) using the format: su - $user $group. Also as I installed the systemd service as per the bitcoin github example I had a different PID location. This ...