Your message dated Wed, 30 Sep 2026 17:46:45 +0200 with message-id <[email protected]> and subject line xfsprogs: xfs_scrub_all deadlocks when lsblk output fills stdout pipe has caused the Debian Bug report #1149535, regarding xfsprogs: xfs_scrub_all deadlocks when lsblk output fills stdout pipe to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1149535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1149535 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: xfsprogs Version: 6.13.0-2+deb13u1 Severity: normal Dear Maintainer, On my hypervisor with many disks, the xfs_scrub_all systemd service hangs indefinitely during its scheduled run. The process state showed: PID PPID STAT WCHAN 4025445 1 SNs do_wait 4025770 4025445 SN anon_pipe_write The parent process was: /usr/bin/python3 /usr/sbin/xfs_scrub_all --auto-media-scan-interval 1mo and the child was: lsblk -o NAME,KNAME,TYPE,FSTYPE,MOUNTPOINT -J /proc/4025770/stack showed: anon_pipe_write vfs_write ksys_write __x64_sys_write strace of the parent showed: wait4(4025770, ... A standalone invocation of the exact lsblk command completed normally: $ time lsblk -o NAME,KNAME,TYPE,FSTYPE,MOUNTPOINT -J > /tmp/lsblk.out real 0m0.042s user 0m0.027s sys 0m0.015s The cause appears to be find_mounts() in /usr/sbin/xfs_scrub_all: result = subprocess.Popen(cmd, stdout=subprocess.PIPE) result.wait() if result.returncode != 0: return fs sarray = [x.decode(sys.stdout.encoding) for x in result.stdout.readlines()] The parent waits for lsblk to terminate before consuming stdout. If lsblk produces enough JSON output to fill the pipe, lsblk blocks in anon_pipe_write waiting for the parent to consume stdout, while the parent blocks in wait4 waiting for lsblk to exit. I locally changed this to use subprocess.run(), so that stdout is consumed without this deadlock: result = subprocess.run(cmd, stdout=subprocess.PIPE) if result.returncode != 0: return fs output = result.stdout.decode(sys.stdout.encoding) After this change: $ time /usr/sbin/xfs_scrub_all real 0m0.447s The systemd service also completed successfully: Process: 4056542 ExecStart=/usr/sbin/xfs_scrub_all --auto-media-scan-interval 1mo (code=exited, status=0/SUCCESS) Main PID: 4056542 (code=exited, status=0/SUCCESS) xfs_scrub_all.service: Deactivated successfully. Finished xfs_scrub_all.service. This appears to correspond to the upstream fix for the xfs_scrub_all deadlock when lsblk produces a large amount of output. Could this fix please be backported to the xfsprogs package in Debian 13/trixie? Upstream fix: https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=1c52b36e3234aedaaa4b467f64c01636e96c1946 Regards, -- System Information: Debian Release: 13.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 7.0.14-14-pve (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfsprogs depends on: ii libblkid1 2.41.5-0+deb13u1 ii libc6 2.41-12+deb13u4 ii libdevmapper1.02.1 2:1.02.205-2+pmx1 ii libedit2 3.1-20250104-1 ii libicu76 76.1-4 ii libinih1 59-1 ii liburcu8t64 0.15.2-2 ii libuuid1 2.41.5-0+deb13u1 ii python3 3.13.5-1 ii python3-dbus 1.4.0-1 xfsprogs recommends no packages. Versions of packages xfsprogs suggests: pn acl <none> ii attr 1:2.5.2-3 pn quota <none> pn xfsdump <none> -- no debconf information
--- End Message ---
--- Begin Message ---Version: 7.2.0-1 The bug now lives at stable update request at #1149545.
--- End Message ---
