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

Runtime Filtering of Log Levels Not Working Properly #72818

Open
satheeshkola opened this issue May 15, 2024 · 3 comments
Open

Runtime Filtering of Log Levels Not Working Properly #72818

satheeshkola opened this issue May 15, 2024 · 3 comments
Assignees
Labels
area: Logging bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug

Comments

@satheeshkola
Copy link

Bug Found: Issue with Runtime Log Level Filtering in Zephyr

Description: I've encountered an issue regarding the runtime filtering of log levels in Zephyr. Despite configuring the project with
LOG_MODULE_REGISTER(MONITOR)

and attempting to set the log filter using api:
log_filter_set(NULL, 0, log_source_id_get(STRINGIFY(MONITOR)), LOG_LEVEL_WRN),

I've noticed that the filtering doesn't apply as expected when the backend parameter is set to null for the module.

Project Configuration Summary:
• 12 frontends and 1 backend are utilized.
• Runtime filtering is enabled with CONFIG_LOG_RUNTIME_FILTERING=y.
• UART backend is disabled with CONFIG_LOG_BACKEND_UART=n.

Expected Behavior: Setting the log level filter using log_filter_set at runtime should effectively control the log output for the specified module.

Actual Behavior: Despite configuring the requested log level here in above eg: LOG_LEVEL_WRN using log_filter_set, the filtering doesn't function as anticipated when the backend parameter is set to null.

Steps to Reproduce:
1. Configure the project as described above.
2. Attempt to set log filtering using log_filter_set at runtime.
3. Observe that the filtering does not behave as expected when the backend parameter is null.

Environment:
Linux,
zephyr-sdk(zephyr 0.16.5)

I kindly request assistance in resolving this issue. Thank you.

@satheeshkola satheeshkola added the bug The issue is a bug, or the PR is fixing a bug label May 15, 2024
Copy link

Hi @satheeshkola! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

@nordic-krch
Copy link
Contributor

Thanks for submitting the issue. Can you clarify few things?

12 frontends and 1 backend are utilized.

What do you mean by 12 frontends? Logging support only one user frontend (log_frontend.h API implementation).
What kind of backend do you use? When is it started (from the beginning or later during runtime?). What is the unexpected behavior (INF level logs are still present vs no logs)? We are using this in samples/subsys/logging/logger and it works correctly there.

@satheeshkola
Copy link
Author

1.I have registered modules, I have registered 12 LOG modules.
2. Custom backend using UART.
3. Custom backed is start from the beginning and trying to change Log level at runtime.
4. Even though i change the log level to WARN still i am getting INF logs.

@nordic-krch nordic-krch pinned this issue May 17, 2024
@erwango erwango unpinned this issue May 17, 2024
@nashif nashif added the priority: low Low impact/importance bug label May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Logging bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

4 participants