#35387 logging: make trace logging easily usable

ReviewabilityReviewsAgreementSize
#35387 ryanofsky logging: make trace logging easily usableWaiting on author0Mild188 + 102 tests
  • Allow loglevel configuration standalone without requiring paired debug flags to take effect
  • Inspect and adjust category log levels at runtime via RPC without restarting the node
  • Author silent for 93 days, so reviews may wait a long time for a response
  • No review verdicts recorded
  • Support for an elegant approach and intuitive interface (stickies-v)
  • Nonblocking objection: maintaining two parallel active logging RPC methods adds maintenance burden (stickies-v)
  • Unaddressed question asking if breaking debug interactions was intended (cyb3ralbert)
  • 188 lines added or modified outside tests
  • 102 lines added or modified in tests
  • 41 lines removed in total
  • 11 files, 2 commits
RPC / REST / ZMQ#43 of 55
P3 · new feature
  • P3 because dynamic runtime log configuration adds useful node control
  • Lacks evidence of demand from external downstream consumers
  • Ranking pass: Moved up 5: same band and same problem as #34038, kept adjacent so the two approaches are compared, but second since #34038 has a dependent PR.
Ranking notes
Utilities (logging, arguments, libraries)#33 of 59
P3 · new feature
  • P3 because decoupling loglevel from debug flags simplifies configuration
  • Aids live node debugging by letting operators change log verbosity on the fly
  • Ranking pass: Placed next to #34038 because both solve the same trace-logging configuration problem and must be decided together.
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

This PR allows the -loglevel configuration option to function standalone without requiring accompanying -debug options to activate categories. It also introduces a new `loglevel` RPC that enables inspecting and adjusting logging levels (trace, debug, info) per category at runtime without restarting bitcoind.

Problem: Trace logging is difficult to discover and enable because -loglevel requires paired -debug flags to take effect. Furthermore, log severity thresholds cannot be modified dynamically at runtime, hindering debugging on live nodes.

Reviewability

Paused · Waiting on author

Open objections from cyb3ralbert, stickies-v with no author reply for 18 days; review would repeat what has been asked.

Waiting on (from the thread read):

  • author: response to stickies-v's review and suggestions, and cyb3ralbert's questions regarding -debug compatibility 2026-10-14

Agreement

Mild

objection that needs an answer has none yet (stickies-v)

Thread notes: Added cyb3ralbert's comment c:6161400215 questioning the change in behavior between -debug and -loglevel contrary to the description's backwards-compatibility claim; cyb3ralbert also agreed with stickies-v's suggestion on config precedence.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
stickies-v (member)objection, interfacemaintaining two parallel active logging RPC methods adds interface redundancy and maintenance burdenopenansweredno2026-05-27: 'I don't think we should have 2 parallel active logging RPC methods, so imo this PR should mark logging deprecated'
stickies-v (member)suggestion, approachreference #34038 as an alternative in the PR descriptionopenansweredno2026-05-27: 'The PR description should probably reference #34038 as an alternativate?'
stickies-v (member)suggestion, interfacesplit the loglevel RPC into separate getlogconfig (read) and setloglevel (single-change write) methodsopenansweredno2026-10-07: 'I think this RPC would be easier to use and reason about if we split it into a read and a write method, where the write method makes a single change per call'
stickies-v (member)suggestion, approachmake -loglevel declarative at startup so category:level always overrides a global level regardless of order or sourceopenansweredno2026-10-07: 'At startup, I think it makes sense for `-loglevel` to be declarative (unlike the RPC, which is imperative).'
cyb3ralbert (contributor)question, correctnessask if breaking -debug interactions when combined with global -loglevel is intended, and if so to document it and remove backwards compatibility claimsopenansweredno2026-10-14: 'With this PR a global `-loglevel` token enables or disables all categories and overrides `-debug`... Is this intended? If so, could the release notes mention it and the description drop "backwards compatible"?'

Support:

  • stickies-v (member) (2026-05-27) [read]: This looks like an elegant approach, I think it's an intuitive RPC and -loglevel interface.

Participants:

  • stickies-v (member, objection, 4 statements 2026-05-27 to 2026-10-07): supports the approach and interface, but objects to having two parallel active logging RPC methods; suggested splitting loglevel RPC and making startup -loglevel declarative
  • sedited (member, neutral, 1 statements 2026-10-02 to 2026-10-02): prompted author to respond to stickies-v's review
  • cyb3ralbert (contributor, question, 1 statements 2026-10-14 to 2026-10-14): tested PR, asked about backwards compatibility and -debug/-loglevel interactions, agreed with stickies-v on config precedence

Files

104 lines under test/bench/ci.

  • src/rpc/node.cpp +95/-19
  • test/functional/feature_logging.py +100/-2
  • src/init/common.cpp +44/-12
  • doc/release-notes-35387.md +27/-0
  • src/logging.cpp +14/-2
  • src/logging.h +5/-6
  • src/init.cpp +1/-0
  • src/init/common.h +1/-0
  • src/rpc/client.cpp +1/-0
  • src/test/fuzz/rpc.cpp +1/-0
  • src/test/logging_tests.cpp +1/-0

Card

The short text the ranking pass compares across PRs.

This PR simplifies trace logging configuration by allowing the -loglevel argument to enable logging categories directly without requiring paired -debug arguments, and introduces a new loglevel RPC to adjust category log levels at runtime. It solves developer and operator friction when inspecting trace-level details on running nodes without needing a restart. Reviewer stickies-v found the approach elegant, though suggested deprecating the legacy logging RPC and pointed out the competing alternative in #34038. The PR is technically ready with green CI, but the author has been silent for over 60 days.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-15T01:16, confidence high, input hash b0dd491a8721fbfc
thread read through 2026-10-14 (7 statements), head dffb8cf9e7
labels: none

Categories

RPC / REST / ZMQ

P3 · new feature (ranking pass: Moved up 5: same band and same problem as #34038, kept adjacent so the two approaches are compared, but second since #34038 has a dependent PR.)

The PR introduces a new `loglevel` RPC to inspect and configure logging levels at runtime, but lacks evidence of external downstream consumer requests.

Membership: Adds a new `loglevel` JSON-RPC method in src/rpc/node.cpp for dynamic log inspection and adjustment.

Factors: security/stability 0, bug 0, performance 0, user value 1, leverage 0

Utilities (logging, arguments, libraries)

P3 · new feature (ranking pass: Placed next to #34038 because both solve the same trace-logging configuration problem and must be decided together.)

Allowing `-loglevel` to function standalone and enabling runtime log adjustments resolves confusing option coupling and aids node debugging.

Membership: Changes logging configuration options and runtime handling in src/logging.cpp and src/init/common.cpp.

Factors: security/stability 0, bug 0, performance 0, user value 1, leverage 0