inxi/pinxi hang on info reports levels 5-8 and F

ANY information report I run with either inxi or pinxi with information level 5 or more, including -Fxz hangs at the location shown below; I forget whether I’ve reported this before or not, so I’ll make SURE to report it today (I haven’t used very long reports recently until now)”

ps ax | head -2; sudo ps_mem.py ; pinxi -Fxz
PID TTY STAT TIME COMMAND
1 ? Ss 0:00 runit
Private + Shared = RAM used Program

108.0 KiB + 15.5 KiB = 123.5 KiB runit
124.0 KiB + 18.5 KiB = 142.5 KiB runsvdir
156.0 KiB + 31.5 KiB = 187.5 KiB seatd
216.0 KiB + 30.5 KiB = 246.5 KiB gpm
300.0 KiB + 30.5 KiB = 330.5 KiB acpid
308.0 KiB + 91.5 KiB = 399.5 KiB cron
276.0 KiB + 189.5 KiB = 465.5 KiB startup
396.0 KiB + 106.5 KiB = 502.5 KiB dbus-launch
368.0 KiB + 228.5 KiB = 596.5 KiB udevil
368.0 KiB + 237.5 KiB = 605.5 KiB icewm-session
432.0 KiB + 292.5 KiB = 724.5 KiB rpcbind
532.0 KiB + 219.5 KiB = 751.5 KiB xcompmgr
480.0 KiB + 291.5 KiB = 771.5 KiB getty (3)
448.0 KiB + 442.0 KiB = 890.0 KiB avahi-daemon (2)
656.0 KiB + 362.5 KiB = 1.0 MiB devmon
712.0 KiB + 478.5 KiB = 1.2 MiB saned
856.0 KiB + 353.5 KiB = 1.2 MiB desktop-session
1.1 MiB + 558.5 KiB = 1.6 MiB dbus-daemon (3)
1.1 MiB + 721.5 KiB = 1.8 MiB at-spi-bus-launcher
1.8 MiB + 317.5 KiB = 2.1 MiB udevd
1.9 MiB + 470.5 KiB = 2.3 MiB bluetoothd
2.0 MiB + 390.5 KiB = 2.4 MiB bash
2.0 MiB + 463.0 KiB = 2.4 MiB runsv (22)
2.0 MiB + 551.5 KiB = 2.5 MiB cupsd
2.3 MiB + 626.5 KiB = 2.9 MiB pipewire
3.2 MiB + 28.5 KiB = 3.2 MiB haveged
2.0 MiB + 1.4 MiB = 3.4 MiB sshd
2.7 MiB + 913.5 KiB = 3.6 MiB conky
3.8 MiB + 201.5 KiB = 4.0 MiB connmand
4.4 MiB + 1.4 MiB = 5.8 MiB slimski
4.6 MiB + 1.2 MiB = 5.8 MiB wpa_supplicant
3.9 MiB + 3.1 MiB = 7.1 MiB wireplumber (2)
6.2 MiB + 2.6 MiB = 8.8 MiB icewm
4.7 MiB + 4.4 MiB = 9.1 MiB volumeicon
12.0 MiB + 1.6 MiB = 13.6 MiB ntpd
948.0 KiB + 18.5 MiB = 19.4 MiB sudo (2)
13.7 MiB + 5.8 MiB = 19.5 MiB roxterm
84.1 MiB + 1.5 MiB = 85.6 MiB Xorg
---------------------------------
216.7 MiB
=================================
System:
Kernel: 6.14.3-1-liquorix-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0
Desktop: IceWM v: 3.7.3 Distro: antiX-23.2-runit_x64 February 26 2025
base: Debian GNU/Linux 12 (bookworm)
Machine:
Type: Convertible System: LENOVO product: 82R7 v: IdeaPad Flex 5 14IAU7
serial: <superuser required>
Mobo: LENOVO model: LNVNB161216 v: SDK0T76473 WIN
serial: <superuser required> UEFI: LENOVO v: J7CN44WW date: 05/24/2023
Battery:
ID-1: BAT0 charge: 52.6 Wh (97.0%) condition: 54.2/52.5 Wh (103.3%)
volts: 12.0 min: 11.5 model: BYD L21B3PE0 status: full
CPU:
Info: 10-core (2-mt/8-st) model: 12th Gen Intel Core i5-1235U bits: 64
type: MST AMCP arch: Alder Lake rev: 4 cache: L1: 928 KiB L2: 6.5 MiB
L3: 12 MiB
Speed (MHz): avg: 2298 min/max: 400/2501 boost: enabled cores: 1: 2298
2: 2298 3: 2298 4: 2298 5: 2298 6: 2298 7: 2298 8: 2298 9: 2298 10: 2298
11: 2298 12: 2298 bogomips: 59904
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Intel Alder Lake-UP3 GT2 [Iris Xe Graphics] vendor: Lenovo
driver: i915 v: kernel arch: Xe bus-ID: 00:02.0
Device-2: Luxvisions Innotech Integrated Camera driver: uvcvideo
type: USB bus-ID: 3-6:3
Display: server: X.Org v: 1.21.1.7 driver: X: loaded: modesetting
unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1920x1200~60Hz
API: EGL v: 1.5 drivers: iris,swrast platforms:
active: gbm,x11,surfaceless,device inactive: wayland
API: OpenGL v: 4.6 vendor: intel mesa v: 22.3.6 glx-v: 1.4
direct-render: yes renderer: Mesa Intel Graphics (ADL GT2)
Info: Tools: api: eglinfo,glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr
^C
Back to top

You can see what is hanging by using:


I'm going to guess it's pipewire hanging, there's an unresolved issue there that inxi can't detect or work around.

That's going to scroll a bunch of stuff, but only the last few lines matter.

Keep in mind, every line item that shows ran successfully, in this case, graphics, so the hang always belongs to the following line item, Audio in this case.

The pipewire hang is an open codeberg inxi issue because there's nothing I can do to stop it, but it is happening.

If it's not pipewire, then it's something new. But you'll see in a minute once you run that command.

All hangs can be located precisely with --debug 3, because that prints out to screen as it chugs along gathering data, not as it prints the gathered data.

This is the codeberg issue: codeberg.org/smxi/inxi/issues/316

Assuming pipewire, that also shows the likely cause, as well as possible ways to work around it. It's caused by a hanging open socket created by something other than pipewire itself, can be a forgotten start command, etc.

I'd consider this as a sort of pipewire bug since it shouldn't hang in this case, it should handle it better internally, but we'll wait and see where your hang actually is.
Back to top

Thanks for the feedback. I'll turn off pipewire and try it out.
If it works, then that's the problem.
CONFIRMED; that's the problem; you can close this issue, though it'd be really nice if the tool worked with pipewire enabled too.
Back to top

Note that I will never be able to solve this problem if people can't find what the actual cause is.

I suspect the sockets issue, a forgotten start command somewhere, is the problem, as the issue I linked to said.

I further suspect that this is actually a bug in pipewire, though I can't prove it, because running a simple query as to pipewire's state should not cause a hang no matter what else has happened.

Because these sound servers are not ideally written, inxi has has to add protections to the basic query commands, because the query commands themselves can change the state, sigh, of the sound server.

So those only run in an active process for that sound server is detected.

This is absolutely in the category of if I can't personally reproduce this, and better, know how to set up the wm/desktop to create this scenario, I will not be able to debug this ever.

Is it 2 pipewire processes running? Is it one, but with something else owning its socket? It's impossible to say.

I would NOT have marked this solved since it's not solved, all that happened is you confirmed the pipewire issue is the cause, as I suspected. That does not get us closer to solving it, it just confirms another case of a pipewire caused hang.

I've never seen this, not on any new distro vm test, nowhere, which leads me to believe it's a forgotten start command, the goal here is to learn how it's being triggered, that way a proper bug report could be filed against pipewire, if it's possible for them to solve it, but without a way to trigger the issue it's doubtful they can solve it eitherr.
Back to top

The codeberg issue poster found this, see if this resolves it. It's probably one single of those load module commands that causes the issue, but no idea which or why.


Back to top