Fedora Account System
Red Hat Associate
Red Hat Customer
After upgrading to Fedora 43, volumeicon no longer displays an icon. gdb shows the application hanging in gtk_status_icon_update_image. Downloading the older version of gdk-pixbuf2 and using LD_PRELOAD to forcefully load the older version made the application work again. Reproducible: Always Steps to Reproduce: 1. install volumeicon 2. run volumeicon Actual Results: No icon appears on the panel Expected Results: A volume icon should appear on the panel Additional Information: I am using the MATE+Compiz spin, and have not tested it on other Desktop Environments
Created attachment 2113804 [details] gdb backtrace of volumeicon
Thanks for your report. To be honest, I'm maintaining volumeicon for legacy reason. Project is very legacy indeed, based on Gtk2, and since those times package existed for usage mostly in early Xfce desktop (now Gtk3 though). Therefore conflicts should not wonder. Last release 0.5.1 of upstream is from 2015. Maybe migration of volumeicon for Gtk3 is not really expected neither announced anyhow, sorry. :o(
Because nowadays wayland instead of Xorg see also https://github.com/Maato/volumeicon/issues/79 .
volumeicon is not a gtk2 application, it links to gtk3. Realizing that this is possibly a threading issue (futex deadlock), I checked the backtraces of other threads There is a thread named "blocking-2", that is hung up in glycin::sandbox::{impl#0}::check_bwrap_syscalls_blocked_internal::{async_fn#0}::{closure#1} () at /usr/share/cargo/registry/glycin-3.0.4/src/sandbox.rs:707 This seems to try running bwrap with /usr/bin/true as a test if bwrap sandboxing works: bwrap --unshare-all --die-with-parent --chdir / --ro-bind /usr /usr --dev /dev --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache --ro-bind-try /nix/store /nix/store --tmpfs /tmp-home --tmpfs /tmp-run --clearenv --setenv HOME /tmp-home --setenv XDG_RUNTIME_DIR /tmp-run --setenv XDG_RUNTIME_DIR /run/user/1000 --symlink /usr/lib64 /lib64 --symlink /usr/lib /lib --seccomp 29 /usr/bin/true This command never completes, gdb shows bwrap stuck in a poll on status_fd and event_fd #3 0x000055b6c7110a05 in poll (__fds=0x7ffc7c736ae0, __nfds=<optimized out>, __timeout=-1) at /usr/include/bits/poll2.h:44 #4 monitor_child (event_fd=4, child_pid=17537, setup_finished_fd=-1) at ../bubblewrap.c:543 #5 main (argc=<optimized out>, argv=<optimized out>) at ../bubblewrap.c:3212 There is a bug report on bubblewrap that bwrap may hang in monitor_child if the parent is ignoring SIGCHLD. I was not able to confirm with gdb if SIGCHLD is being ignored, however applying the patch listed at https://github.com/containers/bubblewrap/pull/711/ was able to make volumeicon start up without issue. It is likely that this issue will resolve itself with a future update to bubblewrap.
Thanks for debugging and verification of gtk3. Mentioning MATE accidently let me think about Gtk2 legacy as my first impression so implicitly wrong assumption. But I'm confused now about your backtrace and gdb. What is relation to bubblewrap/bwrap? The comment in linked pull request talks about kernel internals. What is your suggestion then, patches welcome so should get applied where, could you file another pull request? There are other bugs with gdk-pixbuf2 using glycin. Besides, I tend to blame Wayland as well for not allowing to show an icon in systray, see comment #3. Can you reproduce with Fedora 42 (instead of 43) as well?
FTR bubblewrap has some issues with SELinux, for instance nemo see bug #2411935. Well, I tend to forward this bug to glycin as the currently most obvious cause: gcin, the affected application, uses signal(SIGCHLD, SIG_IGN); gcin eventually uses glycin library glycin uses bwrap From gdb, bwrap is stuck in monitor_child. A fix might be using SIG_DFL for SIGCHLD before executing a process.
Well, I tend to forward this bug to glycin as the currently most obvious cause: ..
This is fixed in bubblewrap-0.11.1 or later, so F45 only at the time of writing. Reassigning to bubblewrap.
Please update bubblewrap or backport https://github.com/containers/bubblewrap/commit/80075f35107d94b781c0de0cedf5cb49d2fcd434 .
FEDORA-2026-3d9bd126ce (bubblewrap-0.12.0-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-3d9bd126ce
FEDORA-2026-96e0765328 (bubblewrap-0.12.0-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-96e0765328
FEDORA-2026-96e0765328 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-96e0765328` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-96e0765328 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-3d9bd126ce has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-3d9bd126ce` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-3d9bd126ce See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-3d9bd126ce (bubblewrap-0.12.0-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-96e0765328 (bubblewrap-0.12.0-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.