Re: coredumpctl: matching by e.g. env var?

[Luca Boccassi <luca.boccassi@xxxxxxxxx>]

On Wed, 15 Mar 2023 at 08:43, Stephan Bergmann <sbergman@xxxxxxxxxx> wrote:
>
> Hi all,
>
> I have a question about coredumpctl core dump matching, maybe somebody
> has an idea:  The LibreOffice build system's `make check` machinery has
> some logic to identify core files generated by crashed tests and to use
> gdb to automatically obtain backtraces from them (similar to
> `coredumpctl debug`; which is especially useful for builds running as
> remote CI jobs, where all you get back is the build log including the
> gdb backtraces).
>
> But that LibreOffice machinery relies on the traditional
> /proc/sys/kernel/core_pattern=core setting.  For each test (which can
> each spawn any number of sub-processes), it first cd's to a dedicated
> per-test directory prior to starting the test, and then when the test
> failed it invokes gdb on any core.* files found in that directory.
> Which worked quite well (hardly any test process would internally
> establish a different cwd).
>
> Now, for environments using coredumpctl rather than the traditional
> core_pattern, I'd like to make that machinery work too.  I'd need some
> way to match exactly those core dumps coming from processes belonging to
> a given test invocation.  (And many different tests use the same test
> runner executable, which rules out matching by COREDUMP_EXE.)  I find no
> journalctl match filter variable in systemd.journal-fields(7) that looks
> like it could help me here.
>
> So one idea I had was whether it could be possible to match by a given
> environment variable value?  The LibreOffice test machinery would set
> some specific environment variable E to a (hopefully) unique per-test
> value V prior to starting a test, and then when the test failed it could
> query `coredumpctl debug` on matches of E=V.
>
> Any thoughts?

Use the elf metadata spec: https://systemd.io/ELF_PACKAGE_METADATA/

I need to update that, as these days it's no longer necessary to use a
custom linker script, but with binutils 2.39 (or mold 1.3.0 or lld
15.0) it's as easy as passing as a linker flag:
--package-metadata='{"foo":"bar"}'
and it will be appended in the right location in the binary.
systemd-coredump will parse that, and attach it as-is as a
COREDUMP_PACKAGE_JSON= field in the journal.
If the json contains fields named 'name' and/or 'version' they will
also be appended independently as COREDUMP_PACKAGE_NAME= and
COREDUMP_PACKAGE_VERSION=

You should be able to add your own identifier in the json and match on
it easily.

Kind regards,
Luca Boccassi