27 Apr
2011
27 Apr
'11
6:46 p.m.
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
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
29 Apr
29 Apr
4:57 p.m.
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.
9:27 p.m.
On 29/04/11 16:57, Holger Hans Peter Freyther wrote:
On 04/27/2011 06:46 PM, Harald Welte wrote:
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?
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.
10:16 p.m.
On 29/04/11 21:27, Pablo Neira Ayuso wrote:
On 29/04/11 16:57, Holger Hans Peter Freyther wrote:
Sorry, I misunderstood the code, my statement above is not true. I'll
investigate what Holger points out.
On 04/27/2011 06:46 PM, Harald Welte wrote:
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? 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.
30 Apr
30 Apr
1:49 a.m.
Hi Holger,
On 29/04/11 16:57, Holger Hans Peter Freyther wrote:
On 04/27/2011 06:46 PM, Harald Welte wrote:
Could you develop the scenario a bit? The problem that you refer would
occur if `-d' and `-e' are used?
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.
2 May
2 May
1:52 p.m.
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
29 Apr
29 Apr
9:24 p.m.
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? :-)
4757
days inactive
4759
days old
6 comments
3 participants
participants (3)
-
Harald Welte -
Holger Hans Peter Freyther -
Pablo Neira Ayuso