Bug#1128079: Bug#1128001: libgdk-pixbuf-2.0-0: version 2.44.5+dfsg-3 makes volumeicon-alsa fail to work

[Simon McVittie]

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