kernel: Replace application log callbacks with file logging #36197

Kernel logging currently invokes application handlers while holding the logger mutex and, in some cases, validation locks. Slow handlers delay the caller, and handlers that call back into the kernel or acquire conflicting locks can deadlock.

This PR replaces those callbacks with the file writer already used by the node. Applications provide a file path through the C API or C++ wrapper, and the existing logger appends messages to that file. A single logging connection owns the file and closes it when destroyed.

This keeps application log handling out of kernel execution while reusing Core’s existing file writer and bounded startup buffer. It also avoids adding a separate delivery queue with its own capacity, overflow, and consumer lifecycle concerns. Applications can read the file independently and forward messages elsewhere.

File output keeps the node’s existing logging behavior: synchronous, best-effort writes with bounded startup buffering.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36197.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #35322 (logging: streamline Logger state and drop redundant methods by ryanofsky)
• #34778 (logging: rewrite macros to enforce restrictions at compile-time, improve efficiency and usability by ryanofsky)
• #34775 (kernel: make logging callback global by stickies-v)
• #34374 (kernel: use struct-based logging and simplify logging interface by stickies-v)
• #33847 (kernel: Improve logging API by ryanofsky)
• #33646 (log: check fclose() results and report safely in logging.cpp by cedwies)
• #30343 (wallet, logging: Replace WalletLogPrintf() with LogInfo() by ryanofsky)
• #30342 (kernel, logging: Pass Logger instances to kernel objects by ryanofsky)
• #29256 (log, refactor: Allow log macros to accept context arguments by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

LLM Linter (✨ experimental)

Possible places where comparison-specific test macros should replace generic comparisons:

• [src/test/kernel/test_kernel.cpp] BOOST_CHECK_THROW(Logger{PathToString(rejected_path)}, std::runtime_error); -> use BOOST_CHECK_EXCEPTION with a predicate that checks the failure reason, if the exact rejection is important.
• [src/test/kernel/test_kernel.cpp] BOOST_CHECK_THROW(Logger{PathToString(rejected_path)}, std::runtime_error); -> use BOOST_CHECK_EXCEPTION with a predicate that checks the failure reason, if the exact rejection is important.
• [src/test/kernel/test_kernel.cpp] BOOST_CHECK_THROW(Logger{std::string_view{}}, std::runtime_error); -> use BOOST_CHECK_EXCEPTION with a predicate that checks the failure reason, if the exact rejection is important.
• [src/test/kernel/test_kernel.cpp] BOOST_CHECK_THROW(Block{invalid_block}, std::runtime_error); -> use BOOST_CHECK_EXCEPTION with a predicate that checks the failure reason, if the exact rejection is important.
• [src/test/logging_tests.cpp] BOOST_CHECK_THROW(logger.StartFileLogging(log_path), std::runtime_error); -> use BOOST_CHECK_EXCEPTION with a predicate that checks the failure reason, if the exact rejection is important.

No Python comparison macro suggestions were found.

^{2026-09-09 07:29:03}

Concept NACK. This increases coupling with node, and increases dependency on filesystem, both of which go against the direction of kernel. I think it's already pretty easy for consumers to not have slow or deadlocking callbacks, so this doesn't seem like an actual problem at the moment, unless you have data / use cases that point to the contrary?

Additionally, both concerns can be addressed by improving the implementation, e.g. less locking, logging on separate threads, etc.

I agree with stickies-v here. It seems fine to give the responsibility of "block the logging callback for as little time as possible" to the consuming developer.