config: clarify host/port for bitcoind config

[raweber42]

Running the frcli audit command fails somehow arbitrarily. For some start/end times it works fine, for some it doesn't and returns a 401 error.

I can audit reports for any time of the year (months, quarter of, half of and full year).

Running frcli audit --loop-category --start_time 1672527600 --end_time 1680299999 for the first quarter of 2023 works just fine. But frcli audit --loop-category --start_time 1680300000 --end_time 1688162399 for the second quarter fails with the error:
[frcli] rpc error: code = Unknown desc = status code: 401, response: ""

Running it without --loop-category has the same behavior.

But running just frcli audit works just fine.

See above. We are running faraday in Kubernetes.

Standalone.

CLI

We build our own image, currently we are using 0.2.11-alpha

Runs on a kubernetes cluster.

Runs on a kubernetes cluster.

I can't find a faraday.log file, where do I get it?

[mrfelton]

Did you ever get past this? We are experiencing something similar

[guggero]

I asked the user for more information over another comms channel but never got more details. My suspicion is that the bitcoind configuration parameters were wrong (the 401 very likely comes from the attempt to connect to bitcoind from Faraday directly).

[mrfelton]

I'm able to connect to bitdcoind manually from the same container that faraday is running on, using the same connection details that faraday is using

[guggero]

Then it would be useful to get more logs from faraday...

[mrfelton]

I think the issue may indeed be related to the bitcoind connection. Looks like a possible issue with how we are injecting secrets for the bitcoind connection string, so continuing to investigate that side of things atm.

[mrfelton]

Confirmed - the problem was related to the bitcoin connection. In our cases, two issues. Missing the port from the hostname, and an incorrectly injected secret passed as the password. Thanks.

[guggero]

Okay, thank you for confirming. We could probably update the flag/config description a bit better, at least for the host/port part. Renaming the issue to make it more clear what needs to be done.

[mrfelton]

Part of the trouble debugging is that the issue only seems to manifest if you try to do an audit of a time period that contains channel closes. I assume those are the only cases where it actually attempts to connect to bitcoind. Perhaps doing a connect on startup would enable detection of connection issues much sooner and require a lot less debugging to investigate.