The magic behaviour of 'logging level all LEVEL'

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Keith keith at rhizomatica.org
Fri Jul 27 11:42:11 UTC 2018



On 26/07/2018 16:20, Neels Hofmeyr wrote:
>
> true. Any opinions on this one, Keith maybe?
>

I have now got used to using a number of pre-prepared expect
scripts to open VTYs for various logging scenarios.

Rather than changing the logging in an open VTY, I would
probably open another and change it there, or copy and
modify the script to setup that logging config. I haven't
got around to it yet, but I am planning on making this just
one script that accepts params like "msc" or "mgw" as well
as logging configs concepts as I can never remember the
ports now with all the programs, although I have this:

sudo netstat -tapn | egrep 'LISTEN.*osmo' | awk '{print $4,
$7}' | awk -F "[:/ ]" '{print $2,"- " $4}' | grep 42 | sort -n

I did not particularly have a problem with "logging level
all everything" and "logging level all debug" and yes, as
Neels mentioned have been patching libosmocore to revert to
allowing "logging level all everything" - Despite some
strange resistance to belief from some parties, this
actually worked (works) as a temporary ON/OFF switch to set
all categorys to debug, then revert to individual per
category levels. I've explained that before, here on the
list with Max, I think.
The semantics off "logging level all everything" was no more
difficult that anything else in GSM's world of acronyms etc.
It was simply a case of learning what it does.

I think it might be nice to have a default VTY logging
storable in the config as we do for stderr.
Otherwise, I'm kind of OK with using expect to setup what I
want.

K.






More information about the OpenBSC mailing list