Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logger config #2943

Open
MarkoMin opened this issue Mar 17, 2025 · 3 comments
Open

Logger config #2943

MarkoMin opened this issue Mar 17, 2025 · 3 comments

Comments

@MarkoMin
Copy link
Contributor

Following an Logger example I noticed that basic alternation of default handler doesn't seem to work in combination with rebar3 shell:

[{kernel,
  [{logger,
    [{handler, default, logger_std_h,
      #{config => #{file => "path/to/file.log"}}}]}]}].

This gives no result, configuration is not applied.

When I call erl -config config/sys.config the configuration is applied as it should be. Even after I call logger:reconfigure/0, the configuration stays the same. However, when I do rebar3 shell with the same sys config file, it seems to be ignored. What is weird is that if I slightly modify the config by first setting default handler to undefined, then it works:

[{kernel,
  [{logger,
    [{handler, default, undefined},
     {handler, default, logger_std_h,
      #{config => #{file => "path/to/file.log"}}}]}]}].

The behavior seems to be specific only for the default handler.

Using Rebar 3.24.0 with OTP 27.1.2

@ferd
Copy link
Collaborator

ferd commented Mar 17, 2025

Yeah I believe by default rebar3 shell only may touch the logger config when calling rebar_utils:reread_config/2

This sequence of calls goes to reread_logger_config() where it does a sort of big re-application of all values

I think logger:reconfigure/0 wasn't around when I wrote this code (back in OTP-21, reconfigure is there since OTP-24), so replacing that function by a thing that writes to the kernel config and calls the reloading code would work, since OTP-24 is within the range of versions we take for granted now.

@MarkoMin
Copy link
Contributor Author

The reason why it's failing is that logger:update_handler/2 returns {error, {invalid_config_change, ...}} which is silently ignored.

I tried to replace reread_logger_config/0 with logger:reconfigure/0, but I've got weird {fail,"cth_readable_failonly:on_tc_fail/3 CTH call failed"} error for every testcase in the project (not just rebar_utils_SUITE) and I have no idea why does it happen.

I tried swapping logger:update_handler/2 with logger:remove_handler/1 and logger:add_handler/3 and it works correctly. However, there is a small risk of loosing logs between those two so I'd rather us reconfigure if possible.

Do you have any clue whats causing that cth_readable_failonly error? Reconfiguration just removes all handlers and then adds them again after rereading conf...

@ferd
Copy link
Collaborator

ferd commented Mar 18, 2025

oh yeah. Common Test hooks add their own config in there and call the same function. Probably means that CT tests need to change how they're passing their config to also support this pattern by interacting with kernel options before and after the tests. Woops, that increases scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants