]> git.ipfire.org Git - thirdparty/systemd.git/commit
profile/systemd-osc-context: Acknowledge uncertainty
authorChris Lindee <chris.lindee+github@gmail.com>
Mon, 16 Feb 2026 06:47:15 +0000 (00:47 -0600)
committerChris Lindee <chris.lindee+github@gmail.com>
Mon, 16 Feb 2026 09:15:51 +0000 (03:15 -0600)
commitb88ab1c2dd8896a4bb710316b6a949817ef8d859
tree410b5a46abe1234e26e6078ecaf14e1ba66028e6
parent3de092fad7708a2ff587a55c52c62ece1a13f40b
profile/systemd-osc-context: Acknowledge uncertainty

Bash does not provide an easy way to discern if an exit status came from
a signal, or was a legitimate non-zero exit (i.e. a failure).  It can be
done, by using job control or by invoking another program; however, such
approaches require modifying the command entered by a user and are, thus,
invasive and risky.

Since an exit status of 129 on a command could either indicate it exited
cleanly with `exit(129)` or was interrupted by `SIGHUP`, the osc context
should report both possibilities, to acknowledge our uncertainty.  Given
we have no idea what happened, besides an unsuccessful exit, the exit is
described as `exit=failure`.

Moreover, discerning between an `interrupt` and a `crash` with a command
likely involves categorizing every signal.  It is fairly obvious `SIGINT`
is an interrupt and also obvious, IMO, that `SIGSEGV` is a crash.  Avoid
the complication (and potential disagreements) by using the encompassing,
generic value — one that remains true if no signal occurred.

References:
 [0] https://stackoverflow.com/a/66431355
profile.d/80-systemd-osc-context.sh