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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 28, 2023 at 9:13 AM Stephan Bergmann <sbergman@xxxxxxxxxx> wrote:
On 27/03/2023 13:38, Lennart Poettering wrote:
> another idea: can't you just wrap your tests in "systemd-run --scope
> --user --name=somtestid47110815.scope" or so? we pick up unit
> names in coredump handling. With that you'd run yur tests inside a
> scope unit, and can then use that as key in logs+coredump.

Thanks, that looks useful, `systemd-run --scope --user --unit=... ...`
and `coredumpctl debug COREDUMP_USER_UNIT=....scope ...`.

* Is it guaranteed for system-run --scope that the wrapped command will
run in the surrounding process group?  (Because LibreOffice' Jenkins
relies on a single process group for a whole `make check` to reliably
kill stuck builds.  And it looks like systemd-run --scope is just a
lightweight wrapper that then exec's the command in the same process,
which looks promising.)

While I'm not sure about whether the same pgroup is guaranteed, once you've started using scopes it might be more reliable to *systemctl stop the scope* in order to kill a stuck build, without relying on process groups anymore.
 

* Is there a grammar for those --unit=X resp.
COREDUMP_USER_UNIT=X'.scope values?  I noticed that at least "/" in X
gets replaced with "-" in X'.  Is there a length limit?

Slashes are not supported in unit names (translated to a dash as part of the escaping), as a unit name has to be a valid filename. The "@" has special meaning (indicates instance name for .service units; I don't think that's supported for .scope units though). Usually "foo-bar-baz-12345.scope" is the typical format.

--
Mantas Mikulėnas

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux