syslog-ng
syslog-ng copied to clipboard
syslog-ng
Set loglevels from config
This patch adds a feature to control the internal verbosity of syslog-ng (e.g. verbose, debug, trace) via the configuration file.
Example:
options {
log-level(debug);
};
Possible values for log-level: - default, just normal log messages - verbose, normal + messages that get enabled via -v - debug, verbose + messages that get enabled via -d - trace, debug + messages that get enabled via -t
If the option is unset, we leave the settings as specified on the command line.
If we have log-level(default) it would override settings specified via the command line.
Rationale: in containerized environments, it is much easier to override log verbosity settings via the config file than via changing the command line options.
No news file has been detected. Please write one, if applicable.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request introduces 1 alert when merging 20c4f4daafa815b8a178b47e1dd85fa983388641 into d8d8d0fced4b05ff22ee47f408ab6ddafd8965a8 - view on LGTM.com
new alerts:
- 1 for Comparison result is always the same
![lgtm-com[bot] avatar](https://avatars.githubusercontent.com/in/17324?v=4 "Published by a pub.dev verified publisher"){kind=small}
Shouldn't we work the other way around? Command line options are usually stronger than configuration file options as they are easier to modify. For example, starting syslog-ng with -d is much quicker than removing/changing the option in the config.
AFAIK other tools work similarly, for example, nginx has a command line flag to override a few directives inside the config file.
Good point.
On Fri, Jul 29, 2022, 18:29 László Várady @.***> wrote:
Shouldn't we work the other way around? Command line options are usually stronger than configuration file options as they are easier to modify. For example, starting syslog-ng with -d is much quicker than removing/changing the option in the config.
AFAIK other tools work similarly, for example, nginx has an option to override a few directives inside the config file.
— Reply to this email directly, view it on GitHub https://github.com/syslog-ng/syslog-ng/pull/4091#issuecomment-1199683855, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFOK5RUSHEABRG6WZXKY73VWQBH3ANCNFSM55ALLVVQ . You are receiving this because you authored the thread.Message ID: @.***>
@kira-syslogng seems to build on the response from "syslog-ng-ctl debug" which was changed by this PR. Can anyone help me with fixing that dependency?
@kira-syslogng test this please test branch=followup_log_level_changes; test=functions/tools/syslog-ng-ctl/;
@kira-syslogng test this please test branch=followup_log_level_changes; test=functions/tools/syslog-ng-ctl/;
I'm just thinking out loud:
This PR deliberately replaces our composable diagnostic flags -Fdevt with a more straightforward approach: log levels.
This means that the -Fdevt is not considered useful anymore as -Fet produces the same level.
In that case, we could say that the old syslog-ng-ctl commands are just for backward compatibility (deprecated), log-level should be used instead. I think the same is true for the command line flags: Since using -dvt is not intuitive anymore either, a --log-level flag would be really useful and could maintain a consistent feel.
Just for the record about the latest failing Kira job. Somehow Jenkins clones out not the PR itself, but the master branch, and because of this the test assertion fails. In the other Kira test job everything is ok, new testcase assertion passes on PR changes.
Latest Kira-starter job runs correctly (I have fixed the Kira job):
- it uses this PR as a source in both cases (cmake and autotools build), and
- the correct topic branch for testdb
Thanks @mitzkia
With that I think we can merge this once it gets a thumbs up from someone.