[feature] bitcoin-cli log

Sjors commented at 8:18 am on February 19, 2019: member

The location of log files depends on the operating system and on which network you’re using.

It would be nice to have a shortcut which wraps tail [-f] <datadir>/<network>/debug.log. It would do what bitcoind -printtoconsole does now, but for bitcoin-cli so you don’t have to restart.

A simpler alternative is a command that returns the log path, e.g.:

0tail -f `bitcoin-cli logpath`

fanquake added the label Feature on Feb 19, 2019

fanquake added the label Utils/log/libs on Feb 19, 2019

darosior commented at 11:04 am on February 25, 2019: member

Which command outputs should / should not be logged ? Should we log commands too ?

Sjors commented at 11:47 am on February 25, 2019: member

@darosior this doesn’t change what we already log, it’s a shortcut to the existing debug.log

darosior commented at 3:29 pm on February 25, 2019: member

@Sjors sorry I didn’t read carefully enough. I think it’s a good idea.

ryanofsky commented at 3:49 pm on February 25, 2019: member

I think it’d be better to add this to an existing get*info RPC method instead of having a new method, so the overall RPC interface and implementation could be simpler, and the information might be more discoverable. Out of getblockchaininfo, getnetworkinfo, getrpcinfo, and getwalletinfo, getrpcinfo might make the most sense.

Sjors commented at 7:26 pm on February 25, 2019: member

@ryanofsky if we merely return the log path, then I agree. Though maybe it does require a new call like getprocessinfo, especially if we end up with potentially multiple log files in #10102?

ryanofsky commented at 7:43 pm on February 25, 2019: member

I wouldn’t want a getprocessinfo to be added for #10102. It is true that in #10102, the bitcoin-node RPC interface is still used to access wallets. But this is just for backwards compatibility. After #10102, I think it would make more sense for wallet processes to listen on their own RPC ports, and for the node process not to be involved at all starting wallets, stopping wallets, forwarding RPC requests to wallets, or returning any information about them in it’s own RPC interface.

Sjors commented at 8:07 pm on February 25, 2019: member

Ok, then adding a logpath entry to getrpcinfo seems reasonable.

darosior referenced this in commit ac071a9f22 on Feb 26, 2019

darosior referenced this in commit bf50477f51 on Feb 26, 2019

promag commented at 9:42 pm on February 26, 2019: member

Why get this via RPC? Could just run, let’s say bitcoind -testnet -printconfig?

darosior commented at 9:55 pm on February 26, 2019: member

Or another command like bitcoin-cli getconfig. But the initial behaviour wanted was about logs :

It would be nice to have a shortcut which wraps tail [-f] <datadir>/<network>/debug.log. It would do what bitcoind -printtoconsole does now, but for bitcoin-cli so you don’t have to restart.

promag commented at 9:58 pm on February 26, 2019: member

Or another command like bitcoin-cli getconfig.

That would be a RPC command. I’m trying to understand if running the above (example) command would be enough.

darosior commented at 10:00 pm on February 26, 2019: member

Yes but it is precisely about not using bitcoind. Why do you think we should not use RPC ?

promag commented at 10:41 pm on February 26, 2019: member

Well I just think it sounds bad - but a RPC getconfig would be better than adding to getrpcinfo IMO.

Having, for instance, bitcoind -printconfig sounds cool because it would work even if you don’t have the daemon running. It would also work if you specify other args like -testnet. It would be a cool way to evaluate config changes.

Edit: the result of bitcoind -printconfig would be just that, the config is printed and then the process terminates.

darosior commented at 11:05 pm on February 26, 2019: member

I think a getconfig command could be helpful, but do you have an idea of what it should returns in addition to the logpath or (datadir) ? But it would be aside from a getlogs command (which I still think could be helpful too) and we maybe should discuss it in another issue ?

Sjors commented at 1:52 pm on February 27, 2019: member

I like to avoid the need to restart bitcoind.

If bitcoind -testnet -printconfig works without stopping an existing node and can return something easily parseable like JSON, then that’s probably fine.

One argument against getrpcinfo is that you can’t get to the log file immediately, because of error code: -28 ... Loading block index..., though I consider that an unrelated RPC bug.

promag commented at 2:46 pm on February 27, 2019: member

I like to avoid the need to restart bitcoind.

If bitcoind -testnet -printconfig works without stopping an existing node and can return something easily parseable like JSON, then that’s probably fine.

Yes, it works with bitcoind running.

laanwj referenced this in commit 9339008a9d on Jul 3, 2019

sidhujag referenced this in commit 0c4a164272 on Jul 5, 2019

Sjors commented at 2:29 pm on July 5, 2019: member

Fixed by #15483.

Sjors closed this on Jul 5, 2019

Munkybooty referenced this in commit 000f27ade6 on Nov 4, 2021

Munkybooty referenced this in commit a0a360917b on Nov 4, 2021

MarcoFalke locked this on Dec 16, 2021

[feature] bitcoin-cli log #15438