BABELTRACE2-RUN(1)

πŸ’– BABELTRACE2-RUN(1) β€” the Babeltrace 2 manual, bestie edition πŸ’–

okay so this is babeltrace2-run from the Babeltrace 2 manual, and it's genuinely one of my faves, no cap 🫢


✨ NAME ✨

babeltrace2-run β€” make a Babeltrace 2 trace processing graph and then, like, run it πŸ’…


🌸 SYNOPSIS 🌸

babeltrace2 [GENERAL OPTIONS] run [--retry-duration=TIME-US]
            [--allowed-mip-versions=VERSION]
            --connect=CONN-RULE... COMPONENTS

πŸ¦‹ DESCRIPTION πŸ¦‹

The run command creates a Babeltrace 2 trace processing graph and runs it. That's it, that's the vibe. ✨

Go read babeltrace2-intro(7) if you wanna know more about the Babeltrace 2 project and its core concepts β€” it's giving required reading, lowkey.

The run command dynamically loads Babeltrace 2 plugins which supply component classes. With run, you say which component classes to instantiate as components, and how to connect them together. You're the main character here, fr fr πŸ‘‘

The steps to write a babeltrace2 run command line are:

  1. Specify which component classes to instantiate as components with many --component options, and how to configure them.

This is the COMPONENTS part of the synopsis. Peep β€œCreate components” below to learn more.

  1. Specify how to connect components together with one or more --connect options.

See β€œConnect components” to learn more.

Note πŸ™ˆ The babeltrace2-convert(1) command is a specialization of the run command for the very common case of converting one or more traces: it generates a run command line and executes it. You can use its --run-args or --run-args-0 option to make it print the equivalent run command line instead. iconic behaviour honestly.

πŸŽ€ Create components πŸŽ€

To create a component, use the --component option. This option specifies:

  • The name of the component, unique amongst all the component names of the trace processing graph.
  • The type of the component class to instantiate: source, filter, or sink.
  • The name of the plugin in which to find the component class to instantiate.
  • The name of the component class to instantiate.

Use the --component option multiple times to create multiple components. You can instantiate the same component class multiple times as different components β€” go off, honestly πŸ’…

At any point in the command line, the --base-params sets the current base initialization parameters and the --reset-base-params resets them. When you specify a --component option, its initial initialization parameters are a copy of the current base initialization parameters.

Immediately following a --component option on the command line, the created component is known as the current component (until the next --component option). yes bestie, the spotlight moves, that's just how it is.

The --params=PARAMS option adds parameters to the initialization parameters of the current component. If PARAMS contains a key which exists in the initialization parameters of the current component, then this parameter is replaced. not merged, not vibed with β€” replaced. πŸ’€


🌈 Connect components 🌈

The components which you create from component classes with the --component option (see β€œCreate components”) add input and output ports depending on their type. An output port is from where messages, like trace events, are sent. An input port is where messages are received. For a given component, each port has a unique name.

The purpose of the run command is to create a trace processing graph, that is, to know which component ports to connect together. The command achieves this with the help of the connection rules that you provide with one or more --connect=CONN-RULE options.

The format of CONN-RULE is:

UP-COMP-PAT[.UP-PORT-PAT]:DOWN-COMP-PAT[.DOWN-PORT-PAT]
  • UP-COMP-PAT β€” Upstream component name pattern.
  • UP-PORT-PAT β€” Upstream (output) port name pattern.
  • DOWN-COMP-PAT β€” Downstream component name pattern.
  • DOWN-PORT-PAT β€” Downstream (input) port name pattern.

When a source or filter component adds a new output port within the processing graph, the run command does the following to find an input port to connect it to:

For each connection rule (--connect options, in order):
  If the component name of the output port matches UP-COMP-PAT and the
  output port name matches UP-PORT-PAT:
    For each component COMP in the trace processing graph:
      If the name of COMP matches DOWN-COMP-PAT:
        Select the first input port of COMP of which the name matches
        DOWN-PORT-PAT, or fail with no match.

No possible connection: fail with no match.

UP-COMP-PAT, UP-PORT-PAT, DOWN-COMP-PAT, and DOWN-PORT-PAT are globbing patterns where only the wildcard character, *, is special: it matches zero or more characters. You must escape the *, ?, [, ., :, and \ characters with \. ⚠️ don't sleep on those backslashes, bestie.

When you don't specify UP-PORT-PAT or DOWN-PORT-PAT, they're equivalent to *.

You can leverage this connection mechanism to specify fallbacks with a careful use of wildcards, as the order of the --connect options on the command line is significant. For example:

--connect='A.out*:B.in*' --connect=A:B --connect='*:C'

With those connection rules, the run command connects:

  • Any output port of which the name starts with out of component A to the first input port of which the name starts with in of component B.
  • Any other output port of component A to the first available input port of component B.
  • Any other output port (of any component except A) to the first available input port of component C.

The run command fails when it cannot find an input port to which to connect a given output port using the provided connection rules. it's giving "no match found" and it's not shy about it 😭

See β€œEXAMPLES” for more examples. πŸ‘€

✨ OPTIONS ✨

okay bestie, this is the part where you actually get to drive πŸ’… every single flag, default, and value, all of it, no skips.


πŸŽ€ General πŸŽ€

these ones go before the command name, like a lil pre-game ritual. see babeltrace2(1) for the full tea.

  • -d, --debug β€” legacy option, lowkey just --log-level=TRACE wearing a lil hat.
  • -l LVL, --log-level=LVL β€” crank the log level of every known Babeltrace 2 logger to LVL. all of them. at once. iconic.
  • --omit-home-plugin-path β€” don't go looking for plugins in $HOME/.local/lib/babeltrace2/plugins. leave that folder alone fr.
  • --omit-system-plugin-path β€” don't go looking for plugins in /usr/local/lib/babeltrace2/plugins either. not today.
  • --plugin-path=PATH[:PATH]... β€” add PATH to the list of places we hunt for plugins. stack as many as you want.
  • -v, --verbose β€” legacy option, and it's giving --log-level=INFO.

πŸ¦‹ Component creation πŸ¦‹

peep "Create components" for the deep lore ✨

  • -b PARAMS, --base-params=PARAMS β€” set the current base parameters to PARAMS.

you can wipe the current base parameters back to nothing with the --reset-base-params option.

for how PARAMS is formatted, check the --params option below πŸ‘‡

  • -c NAME:COMP-CLS-TYPE.PLUGIN-NAME.COMP-CLS-NAME, --component=NAME:COMP-CLS-TYPE.PLUGIN-NAME.COMP-CLS-NAME β€” make a component called NAME from the component class of type COMP-CLS-TYPE named COMP-CLS-NAME, living inside the plugin named PLUGIN-NAME, and make it the current component. main character behavior.

the values you can use for TYPE are:

  • source, src β€” source component class.
  • filter, flt β€” filter component class.
  • sink β€” sink component class.

this component's initial initialization parameters get copied from the current base initialization parameters (that's the --base-params option up there).

  • -l LVL, --log-level=LVL β€” set the log level of the current component to LVL.

the values you can use for LVL are:

  • NONE, N β€” logging? off. disabled. gone.
  • FATAL, F β€” severe errors that make execution abort immediately.
this level should be enabled in production. yes really.
  • ERROR, E β€” errors that might still let execution keep going.

usually, once one or more errors get reported at this level, the application, plugin, or library won't do anything more useful β€” but it should still exit cleanly.

this level should be enabled in production.
  • WARN, WARNING, W β€” unexpected situations that still let execution continue.
this level should be enabled in production.
  • INFO, I β€” informational messages that highlight progress or important states of the application, plugins, or library.
this level can be enabled in production.
  • DEBUG, D β€” debugging info, with a higher level of detail than the TRACE level.
this level should NOT be enabled in production. not even a little.
  • TRACE, T β€” low-level debugging context info.
this level should NOT be enabled in production. periodt.
  • -p PARAMS, --params=PARAMS β€” add PARAMS to the initialization parameters of the current component.

if PARAMS has a key that already exists in the current component's initialization parameters, the parameter gets replaced. no duplicates allowed, we're not doing that.

the format of PARAMS is a comma-separated list of NAME=VALUE assignments:

NAME=VALUE[,NAME=VALUE]...
  • NAME β€” parameter name (a C identifier, plus the :, ., and - characters).
  • VALUE β€” one of:
    • null, nul, NULL: a null value.
    • true, TRUE, yes, YES: a true boolean value.
    • false, FALSE, no, NO: a false boolean value.
    • binary (0b prefix), octal (0 prefix), decimal, or hexadecimal (0x prefix) unsigned (with + prefix) or signed 64-bit integer.
    • double precision floating point number (scientific notation is accepted, slay).
    • unquoted string with no special characters, and not matching any of the null and boolean value symbols above.
    • double-quoted string (accepts escape characters).
    • array, formatted as an opening [, a comma-separated list of VALUE, and a closing ].
    • map, formatted as an opening {, a comma-separated list of NAME=VALUE assignments, and a closing }.

you may put whitespaces around the individual = (assignment), , (separator), [ (array beginning), ] (array end), { (map beginning), and } (map end) characters. go off.

example:

--params='many=null, fresh=yes, condition=false, squirrel=-782329,
          play=+23, observe=3.14, simple=beef,
          needs-quotes="some string",
          escape.chars-are:allowed="a \" quote",
          things=[1, "hello", 2.71828],
          frog={slow=2, bath=[bike, 23], blind=NO}'
Important β€” just like the example above, make sure you single-quote the whole argument when you run this from a shell, because it can absolutely contain a ton of special characters. protect it bestie 🫢
  • -r, --reset-base-params β€” reset the current base parameters. clean slate energy.

you can set the current base parameters with the --base-params option.


🌈 Component connection 🌈

  • -x CONN-RULE, --connect=CONN-RULE β€” add the connection rule CONN-RULE.

the format of CONN-RULE is:

UP-COMP-PAT[.UP-PORT-PAT]:DOWN-COMP-PAT[.DOWN-PORT-PAT]
  • UP-COMP-PAT β€” upstream component name pattern.
  • UP-PORT-PAT β€” upstream (output) port name pattern.
  • DOWN-COMP-PAT β€” downstream component name pattern.
  • DOWN-PORT-PAT β€” downstream (input) port name pattern.

see "Connect components" to learn more πŸ’–


⭐ Graph configuration ⭐

  • -m VERSION, --allowed-mip-versions=VERSION β€” only let the graph honour version VERSION (0 or 1) of the Message Interchange Protocol (MIP), instead of allowing both versions. pick a lane.
  • --retry-duration=TIME-US β€” set the duration of a single retry to TIME-US Β΅s for when a sink component reports "try again later" (busy network or file system, for example). we wait, we try again, we slay.

default: 100000 (100 ms).


πŸ‘‘ Command information πŸ‘‘

  • -h, --help β€” show the command help and quit. the "just tell me what to do" button.

πŸ’… EXAMPLES πŸ’…

Example 1. create a single-port source component and a single-port sink component and connect them.

$ babeltrace2 run --component=A:src.plug.my-src \
                  --component=B:sink.plug.my-sink \
                  --connect=A:B

possible resulting graph:

+-----------------+    +-------------------+
| src.plug.my-src |    | sink.plug.my-sink |
|       [A]       |    |         [B]       |
|                 |    |                   |
|             out @--->@ in                |
+-----------------+    +-------------------+

Example 2. use the --params option to set the initialization parameters of the current component.

in this example, the --params option only applies to component the-source. it's loyal like that.

$ babeltrace2 run --component=the-source:src.my-plugin.my-src \
                  --params=offset=123,flag=true \
                  --component=the-sink:sink.my-plugin.my-sink \
                  --connect=the-source:the-sink

Example 3. use the --base-params and --reset-base-params options to set and reset the current base initialization parameters.

in this example, the effective initialization parameters of the created components are:

  • Component A β€” offset=1203, flag=false
  • Component B β€” offset=1203, flag=true, type=event
  • Component C β€” ratio=0.25
$ babeltrace2 run --base-params=offset=1203,flag=false \
                  --component=A:src.plugin.compcls \
                  --component=B:flt.plugin.compcls \
                  --params=flag=true,type=event \
                  --reset-base-params \
                  --component=C:sink.plugin.compcls \
                  --params=ratio=0.25 \
                  --connect=A:B --connect=B:C

Example 4. specify a component connection fallback rule.

in this example, any A output port whose name starts with foo gets connected to a B input port whose name starts with nin. any other A output port gets connected to a B input port whose name starts with oth.

the order of the --connect options matters here bestie, this is the whole plot twist: the opposite order would create a system where the first rule is always satisfied, and any A output port β€” whatever its name β€” would get connected to a B input port with a name starting with oth.

$ babeltrace2 run --component=A:src.plug.my-src \
                  --component=B:sink.plug.my-sink \
                  --connect='A.foo*:B:nin*' --connect='A:B.oth*'

possible resulting graph:

+-----------------+    +-------------------+
| src.plug.my-src |    | sink.plug.my-sink |
|       [A]       |    |        [B]        |
|                 |    |                   |
|            foot @--->@ nine              |
|         foodies @--->@ ninja             |
|       some-port @--->@ othello           |
|           hello @--->@ other             |
+-----------------+    +-------------------+

✨ ENVIRONMENT VARIABLES ✨

ok so the vibes are configurable, bestie πŸ’… these env vars are how you whisper sweet nothings to the Babeltrace 2 library, the Python bindings, and the CLI. they're grouped by who listens to them πŸ‘‡

🌸 Babeltrace 2 library

  • BABELTRACE_EXEC_ON_ABORT=CMDLINE β€” run the command line CMDLINE when literally any part of the Babeltrace 2 project unexpectedly aborts. it gets parsed like a UNIX 98 shell would parse it, no cap. the app only actually aborts when the command you ran returns β€” and it fully ignores that command's exit status, so don't come for it about return codes πŸ™ˆ
⚠️ this variable is straight-up ignored when the application has the setuid or setgid access right flag set. security said no πŸ’€
  • BABELTRACE_TERM_COLOR=(AUTO | NEVER | ALWAYS) β€” forces the terminal color support for the babeltrace2(1) program and the project plugins. yes queen, you can override the vibes 🌈

the available values are:

  • AUTO β€” only emit terminal color codes when the standard output and error streams are connected to a color-capable terminal. it reads the room first πŸ’…
  • NEVER β€” never emit terminal color codes. monochrome era 😭
  • ALWAYS β€” always emit terminal color codes. colorful even when nobody asked, iconic behavior ✨
  • BABELTRACE_TERM_COLOR_BRIGHT_MEANS_BOLD=0 β€” set this to 0 to emit SGR codes 90 to 97 for bright colors (SGR = those ANSI escape code guys, see <https://en.wikipedia.org/wiki/ANSI_escape_code>) instead of doing the bold thing (SGR code 1) plus standard color codes (SGR codes 30 to 37). it's giving "choose your fighter" πŸ”₯
  • BABELTRACE_PLUGIN_PATH=PATHS β€” sets the list of directories, in order, where dynamic plugins can be found before any other directories are considered, to PATHS. the separator is a colon (or a semicolon on Windows, because of course πŸͺŸ).
  • LIBBABELTRACE2_DISABLE_PYTHON_PLUGINS=1 β€” disables the loading of any Babeltrace 2 Python plugin. python girlies sit this one out 🐍🚫
  • LIBBABELTRACE2_INIT_LOG_LEVEL=LVL β€” forces the initial log level of the Babeltrace 2 library to be LVL. if this env var is set, it overrides the log level set by the --log-level option for the Babeltrace 2 library logger. env var said "I'm the main character now" πŸ‘‘

the available values for LVL are:

  • NONE, N β€” logging is disabled. silence, but make it chic 🀫
  • FATAL, F β€” severe errors that lead the execution to abort immediately. this level should be enabled in production. very much "this is fine but also everything is on fire" πŸ”₯
  • ERROR, E β€” errors that might still allow the execution to continue. usually, once one or more errors are reported at this level, the application, plugin, or library won't perform any more useful task, but it should still exit cleanly. this level should be enabled in production. we love a graceful exit πŸ’…
  • WARN, WARNING, W β€” unexpected situations which still allow the execution to continue. this level should be enabled in production. "not ideal but we move" energy 🫢
  • INFO, I β€” informational messages that highlight progress or important states of the application, plugins, or library. this level can be enabled in production. cute little progress updates ✨
  • DEBUG, D β€” debugging information, with a higher level of details than the TRACE level. this level should NOT be enabled in production. it's a lot 🫣
  • TRACE, T β€” low-level debugging context information. this level should NOT be enabled in production. the most extra level, fr fr πŸ”
  • LIBBABELTRACE2_NO_DLCLOSE=1 β€” makes the Babeltrace 2 library leave any dynamically loaded modules (plugins and plugin providers) open at exit. this can be useful for debugging purposes. it's like never leaving the group chat, for science πŸ§ͺ
  • LIBBABELTRACE2_PLUGIN_PROVIDER_DIR=DIR β€” sets the directory from which the Babeltrace 2 library dynamically loads plugin provider shared objects to DIR. if this env var is set, it overrides the default plugin provider directory. moving day 🚚

πŸ¦‹ Babeltrace 2 Python bindings

  • BABELTRACE_PYTHON_BT2_LOG_LEVEL=LVL β€” forces the Babeltrace 2 Python bindings log level to be LVL. if this env var is set, it overrides the log level set by the --log-level option for the Python bindings logger. python gets its own volume knob 🎚️

the available values for LVL are:

  • NONE, N β€” logging is disabled. ✨
  • FATAL, F β€” severe errors that lead the execution to abort immediately. this level should be enabled in production. πŸ’€
  • ERROR, E β€” errors that might still allow the execution to continue. usually, once one or more errors are reported at this level, the application, plugin, or library won't perform any more useful task, but it should still exit cleanly. this level should be enabled in production. πŸ’…
  • WARN, WARNING, W β€” unexpected situations which still allow the execution to continue. this level should be enabled in production. 🫢
  • INFO, I β€” informational messages that highlight progress or important states of the application, plugins, or library. this level can be enabled in production. ✨
  • DEBUG, D β€” debugging information, with a higher level of details than the TRACE level. this level should NOT be enabled in production. 🫣
  • TRACE, T β€” low-level debugging context information. this level should NOT be enabled in production. πŸ”

🌈 CLI

  • BABELTRACE_CLI_LOG_LEVEL=LVL β€” forces the log level of the log level babeltrace2 CLI to be LVL. if this env var is set, it overrides the log level set by the --log-level option for the CLI logger. yes, the CLI gets its own too πŸ‘‘

the available values for LVL are:

  • NONE, N β€” logging is disabled. ✨
  • FATAL, F β€” severe errors that lead the execution to abort immediately. this level should be enabled in production. πŸ’€
  • ERROR, E β€” errors that might still allow the execution to continue. usually, once one or more errors are reported at this level, the application, plugin, or library won't perform any more useful task, but it should still exit cleanly. this level should be enabled in production. πŸ’…
  • WARN, WARNING, W β€” unexpected situations which still allow the execution to continue. this level should be enabled in production. 🫢
  • INFO, I β€” informational messages that highlight progress or important states of the application, plugins, or library. this level can be enabled in production. ✨
  • DEBUG, D β€” debugging information, with a higher level of details than the TRACE level. this level should NOT be enabled in production. 🫣
  • TRACE, T β€” low-level debugging context information. this level should NOT be enabled in production. πŸ”
  • BABELTRACE_CLI_WARN_COMMAND_NAME_DIRECTORY_CLASH=0 β€” disables the warning message that babeltrace2-convert(1) prints when you convert a trace with a relative path that's also the name of a babeltrace2 command. yeah that collision is real and it's annoying, this shuts it up πŸ™ˆ
  • BABELTRACE_DEBUG=1 β€” legacy variable: equivalent to setting the --log-level option to TRACE. it's giving old money, throwback vibes πŸ•°οΈ
  • BABELTRACE_VERBOSE=1 β€” legacy variable: equivalent to setting the --log-level option to INFO. also vintage, also valid πŸŽ€

πŸ“ FILES πŸ“

  • $HOME/.local/lib/babeltrace2/plugins β€” user plugin directory. your personal stash 🫢
  • /usr/local/lib/babeltrace2/plugins β€” system plugin directory. the shared one 🏠
  • /usr/local/lib/babeltrace2/plugin-providers β€” system plugin provider directory. where the providers hang out ✨

πŸšͺ EXIT STATUS πŸšͺ

0 on success, 1 otherwise.

that's it, that's the whole personality. either you ate or you didn't πŸ’…


πŸ› BUGS πŸ›

if you encounter any issue or usability problem, please report it on the Babeltrace bug tracker (see <https://bugs.lttng.org/projects/babeltrace>). don't suffer in silence bestie, tell the maintainers, they want to know, fr fr 🫢


πŸ’– RESOURCES πŸ’–

the Babeltrace project shares some communication channels with the LTTng project (see <https://lttng.org/>). yes, they're mutuals 🀝


πŸ‘‘ AUTHORS πŸ‘‘

the Babeltrace 2 project is the result of hard work by many regular developers and occasional contributors. every single one of them ate, no crumbs left 🫢

the current project maintainer is JΓ©rΓ©mie Galarneau <mailto:jeremie.galarneau@efficios.com>. say hi, he's the main character rn πŸ’…


this command is part of the Babeltrace 2 project.

Babeltrace is distributed under the MIT license (see <https://opensource.org/licenses/MIT>). free as in "go off, do your thing" ✨


πŸ‘€ SEE ALSO πŸ‘€

babeltrace2-intro(7), babeltrace2(1), babeltrace2-convert(1)

go read those too, they're the rest of the lore πŸ“š


and that's the whole page, bestie!! πŸŽ€ this was Babeltrace 2.1.2, dated 14 September 2019, and it's the BABELTRACE2-RUN(1) manual β€” you're officially a Babeltrace 2 girlie now, go convert some traces πŸ’–βœ¨

πŸ“¦ where this page comes from