vty_out_uptime() calculates the time difference to a given timespec
and print it in a human readable format (days, hours,
minutes, seconds) to the vty.
Related: OS#5028
Change-Id: I264a3f49096b96646e0a1f5366623ac20d860793
It was so far sufficient to wait for the buffers to drain at some
random point in time, but this is not always the case, sometimes it is
important that the output is flushed immediately.
Change-Id: If984b9ad2eba9f400bc29a7aa8825e241fd1d2a9
Exempt all stat_item statistics from 'stats reset'. Only reset rate_ctr
statistics to zero.
The rate_ctr statistics have an implicit time scale, counting occurences
per time unit. For them it makes sense to reset all ratings and start
from zero, for example in a test suite (e.g. our TTCN3 BSC_Tests).
In contrast, stat_item statistics count number of objects or nr of
specific object stati at any given time, and they do not deteriorate
over time. Many stat items depend on increment/decrement to be sane.
For example, in osmo-bsc, if the nr of connected BTS is 3, that does not
make sense to be reset to zero. There are still 3 BTS connected, only
the stat_item would suddenly reflect zero. From then on, it'd be wrong.
All stat_items are by definition wrong after a 'stats reset'.
- Those that depend on increment/decrement will be wrong until the
program exits, and
- those that are set to absolute values will be wrong up until the next
value is set. That could be seconds or hours later, depending.
Related: SYS#5542
Change-Id: If2134768b1076e7af189276c45f2a09a4944303e
Use ANSI escape characters to clear the screen with ^L, like it works
in typical Linux shells. I always found it slightly inconvenient that
this didn't work in the VTY.
Change-Id: Ie2356cd92f39b4dc28b5c20bbe4557fb0d972747
Kill programs with SIGTERM with the new vty command, as it would happen
with "systemctl stop".
I've considered running the select shutdown logic too in order to ensure
that pending OSMO_FD_WRITE requests are serviced. But as noted in
review, it's better to ensure that the regular SIGTERM code path works
as expected and call that instead of introducing an alternative code
path.
Closes: OS#4609
Change-Id: I3596a35b0f4a24e49484ec3f24a98e4d4f583e1e
Certain control interface commands also may require to verfy a range in
their verify function. cmd_range_match() from the VTY does exactly that
and the range can be specified as string, the same way as we would
specify it in the VTY.
Change-Id: I53fc207677f52b1dc748b01d58424839cdba807c
related: SYS#5369
Use section for all counter headings, the idea is that the generated doc
is included below a chapter describing the implemented counters which
can optionally describe individual items.
If not osmo_counters are present simply omit the whole section to tidy
up the manual. Those are deprecated anyway and not used in the osmo-*
projects that I checked.
Change-Id: I126b39cb9458e0f62efa338967e07151a0eece0f
Related: SYS#5005, OS#4523
This patch adds a new field "name" to the rate_ctr and osmo_stat_item_group
structs, together with an API to set it. This new field allows for easy
identification of specific group instances when several of them exists,
rather than using a sometimes random/increasing index value.
If set, this name (string) is used instead of the index by the stats
reporter.
The name, if set, is also printed during "show stats" VTY commands.
It's up to the user or application to set up unique or meaningful names
to fullfill one's needs.
WARNING: this commit breaks ABI and possibly creates unexpected behavior
when run with non-rebuilt apps which use the modified structs directly
to get the coutners, or if use the static inline API rate_ctr_inc2().
Existing users of these structs should migrate to use new APIs
introduced in follow-up commits instead of accessing the field directly.
Related: SYS#5456
Change-Id: I0dc510783dd9ae8436dae8005a7b3330e80d36f3
This new API doesn't use host_config_set(), and allows passing a FILE*
from any source, not only a filesystem path.
Related: SYS#5369
Change-Id: I720ac04386261628c0798a1bfcaa91e2490a86c3
The library specific sub-systems are kind of special, because their
position in the 'osmo_log_info' may vary depending on the number of
application specific sub-systems. This is why their associated
constant values (like DLGLOBAL) are negative, and this is what
the LOGP() macro expects as the first argument.
Before this change, invoking 'logp' command with any library
specific logging sub-system would result in getting messages
printed with the fall-back DLGLOBAL sub-systems.
Change-Id: If86563e169fe1243adfa7b09c9d65d9f88c8a99e
Back in 2018 in I393907b3c9e0cc1145e102328adad0a83ee13a9f Neels
introduced "last" as an optional flag to log the file/line number at the
end of the line, rather than at the end of the header. It seems nobody
has been usingi this feature, or at least never tried to save a related
config file, as there was no code whatsoever that would ever save this
optional "last" flag.
Change-Id: I7b6245256aecc425722242aaabc154ac58ba27a0
Fixes following ASan runtime errors while running vty tests:
command.c:730:27: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
Somehow we didn't catch this one in Ie11ff18d6fd9f6e1e91a51b6156fb6b0b7d3a9a8
Change-Id: I601caf7daa947f3cf391316f1011007ef9188c90
Having the expert mode flag stored in the global 'host' structure
was a bad idea, because this way it applies globally. In other
words, if user Bob activates the expert mode in his dedicated
session (e.g. a telnet connection), then not only him, but all
other users would see the hidden commands in their VTYs.
Moreover, if somebody deactivates the expert mode, it would also
affect the Bob's VTY session. And finally, terminating a VTY
session would not deactivate the expert mode.
Let's move that flag from the global 'struct host' to 'struct vty'
representing an individual VTY session, so then the expert mode
would only affect the session where it was activated.
In functions related to the XML VTY reference generation we don't
have access to 'struct vty' (there may be no VTY session at all).
Add two additional arguments to vty_dump_nodes(), indicating the
global flag mask and a matching mode. This would allow to match
the VTY commands in many different ways, e.g. one can dump hidden
commands only, or all commands except the library specific ones.
Change-Id: Iba13f0949061e3dadf9cf92829d15e97074fe4ad
Related: SYS#4910
Otherwise in the expert mode, hidden commands do not get the
associated attribute printed to the XML VTY reference.
Change-Id: I8ded973031beb6d8c7ad55f06641c9651b1d9e71
Related: OS#4910
This change introduces an enumerated type 'vty_ref_gen_mode' that
(as the name suggests) defines the VTY reference generation mode:
- DEFAULT - all commands except deprecated and hidden,
- EXPERT - all commands including hidden, excluding deprecated;
and a new function vty_dump_xml_ref_mode(), that allows to specify
that mode. The old vty_dump_xml_ref() is now deprecated.
Change-Id: Ie2022a7f9e167e5ceacf15350c037dd43768ff40
Related: SYS#4910
Some VTY commands are intentionally hidden, e.g. because they might
by relatively dangerous if used in production operation. We equip
such commands with a special attribute - CMD_ATTR_HIDDEN.
The problem is that neiter they appear in the XML VTY reference,
nor in the online VTY help, so it's a bit tricky to invoke them.
This change introduces so-called 'expert' mode, in which hidden
(but not deprecated) commands are getting visible.
In the (telnet) VTY session, this mode can be activated by passing
an additional argument to well-known 'enable' command:
OsmoApp> enable ?
[expert-mode] Enable the expert mode (show hidden commands)
OsmoApp> enable expert-mode
OsmoApp#
so then hidden commands will appear together with all the other
commands. They will be marked with a special '^' flag:
OsmoApp# list with-flags
^ ... foo-hidden [expert-mode]
. ... foo-regular-one
! ... foo-immediate
^ u.. app-hidden-unbelievable
For the XML reference generation, additional API needs to be
introduced. This will be implemented in subsequent patches.
Change-Id: Ie69c2a19b22fb31d7bd7f6412f0aeac86ea5048f
Related: SYS#4910
This change implements 'systemd-journal' logging target, that is
similar to the existing 'syslog' target. The key difference is
that 'systemd-journal' allows us to offload rendering of the meta
information, such as location (file name, line number), subsystem,
and logging level, to systemd. Moreover, we can attach arbitrary,
user-specific fields [1] to the logging messages, so they can be
used for advanced log filtering (e.g. by IMSI/TMSI/TLLI):
$ journalctl OSMO_SUBSYS=DMSC -f
Since we don't want to make libsystemd a required dependency, this
feature is optional, and needs to be enabled at build-time:
$ ./configure --enable-systemd-logging
The new logging target can be configured in the same way as any
other one - via the VTY interface, or using the configuration file:
log systemd-journal [raw]
logging level set-all notice
logging filter all 1
Two logging handlers are available: generic and raw. The first one
behaves similarly to both 'syslog' and 'stderr', i.e. all the meta
information is rendered by libosmocore itself, and then passed to
systemd together with the logging message. The later is more like
the 'gsmtap' target, so all available meta information is handed
over to systemd in form of fields [1]:
- CODE_FILE / CODE_LINE - location info,
- PRIORITY - syslog-compatible logging level,
- OSMO_SUBSYS - Osmocom-specific sub-system (e.g. DMSC),
- OSMO_SUBSYS_HEX - same as OSMO_SUBSYS, but encoded in hex,
- MESSAGE - the logging message itself,
and then can be rendered in any supported format (e.g. JSON).
More details about the API can be found in [2].
[1] https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html
[2] https://www.freedesktop.org/software/systemd/man/sd-journal.html
Change-Id: I609f5cf438e6ad9038d8fc95f00add6aac29fb23
Fixes following ASan runtime errors while running vty tests:
src/vty/command.c:3088:27: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
src/vty/command.c:3136:23: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
Change-Id: Ie11ff18d6fd9f6e1e91a51b6156fb6b0b7d3a9a8
Some attributes like CMD_ATTR_LIB_COMMAND are not being printed
to the XML VTY reference (despite being set), so we should not
print empty "<attributes scope='global'></attributes>".
Change-Id: Ie7e53b080c10564bfef6f0e8ddeb470e46fad387
Related: SYS#4937
Here is an example:
OsmoAPP(config-foo)# list with-flags
... help
... list
... show running-config
... exit
..F lib-command foo (one|two|three)
ZB. lib-command bar [zoo]
.bf app-command foo-bar
z.. app-command zoo .TEXT
... app-command nope
A dot indicates that the associated attribute is not set.
Note that there is no strict relation between rows and index values
of the attributes. In the example above there could be one or more
hidden flag rows corresponding to attributes that are not assigned
to any of the commands within 'config-foo' node.
If neither of the commands belonging to the current node (where
'list' command is executed) has attributes, the output would
not contain empty dot-rows.
Global attributes (such as CMD_ATTR_IMMEDIATE) are not yet displayed
because we still have not agreed on what kind of symbols to assign
them. This will be implemented later.
Change-Id: I71cef3ec0fab44c7e11fc353b8bc42268a4ee8f0
Related: SYS#4937
Here is an example of listing all attributes:
OsmoBSC# show vty-attributes
Global attributes:
. This command is deprecated
. This command is hidden
. This command applies immediately
. This command applies on VTY node exit
Library specific attributes:
(no attributes)
Application specific attributes:
o This command applies on A-bis OML link (re)establishment
r This command applies on A-bis RSL link (re)establishment
or only a specific kind of attributes:
OsmoBSC# show vty-attributes application
Application specific attributes:
o This command applies on A-bis OML link (re)establishment
r This command applies on A-bis RSL link (re)establishment
Change-Id: I561114d7416e30cc06b7d49c0bc1217a76039c99
Related: SYS#4937
This new attribute would allow to distinguish commands provided
by libraries from commands registered by the application itself,
so vty_dump_element() would print proper description for the
library specific attributes.
All VTY commands defined by the libraries need to use the new API:
- install_lib_element(), and
- install_lib_element_ve,
instead of the old functions (respectively):
- install_element(), and
- install_element_ve().
See https://lists.osmocom.org/pipermail/openbsc/2020-October/013278.html.
Change-Id: I8baf31ace93c536421893c2aa4e3d9d298dcbcc6
Related: SYS#4937
Given that commands with either/both of the following attributes:
- CMD_ATTR_DEPRECATED,
- CMD_ATTR_HIDDEN,
never end up in the XML reference, only CMD_ATTR_IMMEDIATE would
be reflected for commands taking effect immediately as follows:
<command id='foo'>
<!-- Global attributes -->
<attributes scope='global'>
<attribute doc='This command applies immediately' />
</attributes>
<!-- Application specific attributes -->
<attributes scope='application'>
<!-- ... -->
</attributes>
<params>
<!-- ... -->
</params>
</command>
Change-Id: I8476c1163c23a9a52641987acf3df0b8c49d8f7b
Related: SYS#4937
Alexander Couzens
Eric Wild
Oliver Smith
Philipp Maier
Daniel Willmann
Vadim Yanitskiy
Pau Espin
Harald Welte