feat: dynamic log level update from patch.cfg without container restart#413
Open
rippleitinnz wants to merge 1 commit into
Open
feat: dynamic log level update from patch.cfg without container restart#413rippleitinnz wants to merge 1 commit into
rippleitinnz wants to merge 1 commit into
Conversation
When log.log_level is present in patch.cfg, apply_patch_config() now updates the live plog logger severity via plog::get()->setMaxSeverity() in addition to persisting the change to hp.cfg and the runtime cfg struct. Previously log level was only read at startup (hplog::init()) and could not be changed on a running node without a container restart. This meant operators had no way to change log verbosity on external Evernode hosts where they don't control the container lifecycle. The fix uses plog's built-in setMaxSeverity() API which is thread-safe and takes effect immediately on the next log statement.
This was referenced May 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
log.log_levelinpatch.cfgis written correctly by the contract upgrademechanism but has no effect on the running node.
hplog::init()sets theplog severity once at startup — there is no code path to update it while
hpcore is running.
This means operators managing Evernode clusters have no way to change log
verbosity on external hosts where they don't control the container lifecycle.
A full container restart is required, which is not possible on leased instances.
Fix
In
apply_patch_config(), after updatingcfg.log.log_levelandcfg.log.log_level_type, callplog::get()->setMaxSeverity()with thenew severity level. This takes effect immediately on the next log statement
without any restart.
The plog library supports this via
Logger::setMaxSeverity()— it isthread-safe and designed for runtime severity changes.
Files changed
src/conf.cpp— addedhplog.hppinclude and dynamic severity update inapply_patch_config()Testing
Tested on a live 14-node Evernode cluster. Log level change via
patch.cfgupdate takes effect within one consensus round (~8-10 seconds) without any
container restart.s built-in setMaxSeverity() API which is thread-safe and takes effect immediately on the next log statement.
Sibling PRs
This is part of a series making some hpcore config fields dynamically updatable from patch.cfg:
feat/dynamic-mesh-idle-timeout-from-patch-cfg— feat: dynamic mesh idle_timeout from patch.cfg without container restart #414feat/dynamic-user-idle-timeout-from-patch-cfg— feat: dynamic user idle_timeout from patch.cfg without container restart #415These three PRs should ideally be reviewed and merged together. PRs #414 and #415
share the
for_each_session()template added tocomm_server.hpp, and all threefollow the same pattern in
apply_patch_config()inconf.cpp.