On Sun, 15 Mar 2026 at 21:19:47 +0100, Johannes Stezenbach wrote:
The key difference in strace is that [after] /usr/bin/true exits
wait4 returns ECHILD instead of its exit status:
16665 20:09:11.648386 exit_group(0) = ?
16665 20:09:11.648590 +++ exited with 0 +++
16663 20:09:11.648604 <... wait4 resumed>, 0x7fff013f71c4, 0, NULL) = -1 ECHILD
(No child processes)
16663 20:09:11.648778 exit_group(1) = ?
16663 20:09:11.649339 +++ exited with 1 +++
I've seen indications in other bug tracking systems that volumeicon
might set SIGCHLD to be ignored. That would be consistent with this
symptom: if SIGCHLD is explicitly ignored (set to SIG_IGN), then the
child process will disappear immediately instead of briefly becoming a
zombie process, therefore it isn't available to be reaped by the parent,
and wait4 and similar functions will fail with ECHILD, making exit
status unavailable.
Unfortunately signal disposition is inheritable state and
process-global, so a parent process ignoring SIGCHLD can break its child
processes' assumptions (as well as libraries in its own process space).
bubblewrap (as used by glycin) relies on process management working
normally. The new bubblewrap 0.11.1 release, which I recently uploaded
to unstable, works around parent processes that ignore SIGCHLD by
explicitly resetting that signal to its default disposition (originally
requested for the benefit of Erlang), which might avoid this failure
mode - although any non-bubblewrap-related library that expects to be able
to wait for subprocesses would likely have the same problem.
I couldn't find evidence of volumeicon ignoring this signal in
codesearch, but perhaps some library that it uses that ignores this
signal, rather than volumeicon itself?
https://codesearch.debian.net/search?q=SIGCHLD+package%3Aalsa-lib&literal=0
does point to alsa-lib (libasound) potentially ignoring SIGCHLD under
some circumstances, although if it does that consistently, I would have
expected it to break subprocess handling in more places. Possibly it
only changes signal disposition when accessing audio devices directly,
and not in clients of a sound server like PulseAudio or Pipewire?
If someone wants to adopt/maintain/reintroduce volumeicon, using a
debugger to find which component ignores SIGCHLD (presumably a call to
signal() or sigaction()) would probably be a useful direction in which
to investigate.
This issue should be reassigned to the rust-glycin package.
I don't think that would be appropriate: it isn't glycin that chose to
ignore SIGCHLD. (If it did, it wouldn't work for anyone, including its
maintainer.)
smcv
