Hi Pablo!
I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work.
This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version.
Maybe you can find some time to investigate and fix the issue.
Thanks in advance, Harald
On 04/27/2011 06:46 PM, Harald Welte wrote:
Hi Pablo!
I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work.
This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version.
I have seen that '-e 1' specified on the CLI will be ignored (at least on osmo-bsc). I think we should define an order of when to apply this and when to read the config file.
On 29/04/11 16:57, Holger Hans Peter Freyther wrote:
On 04/27/2011 06:46 PM, Harald Welte wrote:
Hi Pablo!
I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work.
This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version.
I have seen that '-e 1' specified on the CLI will be ignored (at least on osmo-bsc). I think we should define an order of when to apply this and when to read the config file.
It seems -e 1 is broken if:
* -d is not passed * -d is passed after -e.
We don't check this sort of dependencies. May this be related to the problem that you noticed?
On 29/04/11 21:27, Pablo Neira Ayuso wrote:
On 29/04/11 16:57, Holger Hans Peter Freyther wrote:
On 04/27/2011 06:46 PM, Harald Welte wrote:
Hi Pablo!
I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work.
This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version.
I have seen that '-e 1' specified on the CLI will be ignored (at least on osmo-bsc). I think we should define an order of when to apply this and when to read the config file.
It seems -e 1 is broken if:
- -d is not passed
- -d is passed after -e.
We don't check this sort of dependencies. May this be related to the problem that you noticed?
Sorry, I misunderstood the code, my statement above is not true. I'll investigate what Holger points out.
Hi Holger,
On 29/04/11 16:57, Holger Hans Peter Freyther wrote:
On 04/27/2011 06:46 PM, Harald Welte wrote:
Hi Pablo!
I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work.
This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version.
I have seen that '-e 1' specified on the CLI will be ignored (at least on osmo-bsc). I think we should define an order of when to apply this and when to read the config file.
Could you develop the scenario a bit? The problem that you refer would occur if `-d' and `-e' are used?
On 04/30/2011 01:49 AM, Pablo Neira Ayuso wrote:
Could you develop the scenario a bit? The problem that you refer would occur if `-d' and `-e' are used?
Hi,
the attached config file is the result of 'write' in the VTY code, e.g. it contains the current stderr config.
$ ./src/osmo-bsc/osmo-bsc -c openbsc.bsc -e 1
now the -e 1 is applied (log_set_log_level(stderr_target, atoi(optarg));) before the call to bsc_bootstrap_network. So somehow we should define what takes precedence and make this work across our utilities. E.g. osmo-bsc and osmi-nitb behave the same right now (-e 1 being ignored if stderr is configured in the config file).
With osmo-bsc one sees a lot more messages on startup if -e 1 is applied.
holger
On 27/04/11 18:46, Harald Welte wrote:
Hi Pablo!
I've recently received a bug report that somehow the config-file-stored configuration of which log levels/subsystems to enable on stderr don't work.
This may be related to the legacy "-d DINP:DNM:... style log level specifications, e.g. we first read the config file and then set some default logging options usign the legacy version.
It seems to be the opposite as for the existing code.
Maybe you can find some time to investigate and fix the issue.
Looking at the code, we first parse the command line options and, then, the config file (by calling bsc_bootstrap_network).
Extracted from libosmocore/src/vty/logging_vty.c:
DEFUN(cfg_log_stderr, cfg_log_stderr_cmd, "log stderr", LOG_STR "Logging via STDERR of the process\n") { struct log_target *tgt;
tgt = log_target_find(LOG_TGT_TYPE_STDERR, NULL); if (!tgt) { tgt = log_target_create_stderr(); if (!tgt) { vty_out(vty, "%% Unable to create stderr log%s", VTY_NEWLINE); return CMD_WARNING; } log_add_target(tgt); }
In the config file parsing, it seems that we skip adding a logging target of stderr type if we already got one for stderr.
This looks fine to me, since the command line options should override the config file settings. Should we consider this feature instead of a bug? :-)
-
Harald Welte -
Holger Hans Peter Freyther -
Pablo Neira Ayuso