Description of problem: Upstream commit 87c8343d fixed an fd leak in the log and stats filter. Then the stable-1.12 branch backported only half of that patch (since 1.12 only has the log filter - see commit 6ff66608). But the rhel-8.1 branch backported the stats filter, so it should also backport the fd leak fix (or rebase to the upcoming nbdkit 1.14 release). Version-Release number of selected component (if applicable): nbdkit 1.12.5 (see the upstream rhel-8.1 branch) How reproducible: Steps to Reproduce: 1. The sh plugin coupled with the stats filter can be used to check for fd leaks: ./nbdkit -U - --filter=log --filter=stats sh - \ logfile=/dev/null statsfile=/dev/null \ --run 'qemu-io -r -f raw -c "r 0 1" $nbd' <<\EOF case $1 in get_size) echo 1m;; pread) ls -l /proc/$$/fd >/dev/tty dd iflag=count_bytes count=$3 if=/dev/zero || exit 1 ;; *) exit 2 ;; esac EOF 2. 3. Actual results: If there are any fds > 2 pointing to pipes, sockets, or /dev/null in the output, nbdkit is leaking fds. Expected results: Just stdin/out/err and the script itself should be listed. Additional info:
I pushed commit 6da50ee7 to the upstream rhel-8.1 branch which backports both the log and stats filter fixes. If we rebase the few rhel-8.1 patches on top of stable-1.12 (moving from 1.12.5 to 1.12.6 as the baseline), that rebase action will rewrite the commit to just the stats filter fix (since the rest of stable-1.12 will pick up the log fix). If we rebase rhel-8.1 to the 1.14 release instead, then we don't need any rhel-specific patches backported on top.
In RHEL 8.2 we've rebased to nbdkit 1.16 which should fix this one hopefully. Ideally therefore nothing needs to be done from a dev p.o.v.
Reproduce the bug with builds: nbdkit-1.12.5-2.module+el8.1.1+5309+6d656f05.x86_64 nbdkit-basic-filters-1.12.5-2.module+el8.1.1+5309+6d656f05.x86_64 nbdkit-basic-plugins-1.12.5-2.module+el8.1.1+5309+6d656f05.x86_64 Steps to reproduce: 1. Use sh plugin coupled with stats and log filter to check fd leaks: # nbdkit -U - --filter=log --filter=stats sh - logfile=/dev/null statsfile=/dev/null --run 'qemu-io -r -f raw -c "r 0 1" $nbd' <<\EOF case $1 in get_size) echo 1m;; pread) ls -l /proc/$$/fd >/dev/tty dd iflag=count_bytes count=$3 if=/dev/zero || exit 1 ;; *) exit 2 ;; esac EOF total 0 lr-x------. 1 root root 64 Feb 6 07:27 0 -> 'pipe:[4078705]' l-wx------. 1 root root 64 Feb 6 07:27 1 -> 'pipe:[4078706]' l-wx------. 1 root root 64 Feb 6 07:27 2 -> 'pipe:[4078707]' lr-x------. 1 root root 64 Feb 6 07:27 255 -> /tmp/nbdkitshMqVbqu/inline-script.sh lr-x------. 1 root root 64 Feb 6 07:27 5 -> 'pipe:[4075386]' l-wx------. 1 root root 64 Feb 6 07:27 6 -> 'pipe:[4075386]' lrwx------. 1 root root 64 Feb 6 07:27 8 -> 'socket:[4079701]' read 1/1 bytes at offset 0 1 bytes, 1 ops; 00.01 sec (115.316446 bytes/sec and 115.3164 ops/sec) Reproduced result: There are fd > 2 pointing to pipes and sockets info in the output, so nbdkit is leaking fds. Verify the bug with builds: nbdkit-1.16.2-1.module+el8.2.0+5579+d71178e0.x86_64 nbdkit-basic-plugins-1.16.2-1.module+el8.2.0+5579+d71178e0.x86_64 nbdkit-basic-filters-1.16.2-1.module+el8.2.0+5579+d71178e0.x86_64 Steps: 1. Use sh plugin coupled with stats and log filter to check fd leaks: # nbdkit -U - --filter=log --filter=stats sh - logfile=/dev/null statsfile=/dev/null --run 'qemu-io -r -f raw -c "r 0 1" $nbd' <<\EOF case $1 in get_size) echo 1m;; pread) ls -l /proc/$$/fd >/dev/tty dd iflag=count_bytes count=$3 if=/dev/zero || exit 1 ;; *) exit 2 ;; esac EOF total 0 lr-x------. 1 root root 64 Feb 6 07:36 0 -> 'pipe:[58694]' l-wx------. 1 root root 64 Feb 6 07:36 1 -> 'pipe:[58695]' l-wx------. 1 root root 64 Feb 6 07:36 2 -> 'pipe:[58696]' lr-x------. 1 root root 64 Feb 6 07:36 255 -> /tmp/nbdkitshNBgNQc/inline-script.sh read 1/1 bytes at offset 0 1 bytes, 1 ops; 00.01 sec (82.760130 bytes/sec and 82.7601 ops/sec) Result: There is no fd > 2 pointing to pipes, sockets or /dev/null in the output, so the bug has been fixed, move the bug from ON_QA to VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2017