Bug#619650: File descriptor 4 (pipe:[556425]) leaked on lvs invocation. Parent PID 17535: /bin/sh

[Jonathan Nieder]

reassign 619650 cupt 2.0.0~beta2
retitle 619650 cupt: various fds leak to maintainer scripts
quit

Colin Watson wrote:
> On Fri, Mar 25, 2011 at 03:26:10PM -0500, Jonathan Nieder wrote:

>> | # cupt full-upgrade
>> [...]
>> | Setting up grub-pc (1.99~rc1-5) ...
>> | Installation finished. No error reported.
>> | Generating grub.cfg ...
>> | Found background image: /usr/share/images/desktop-base/desktop-grub.png
>> | Found linux image: /boot/vmlinuz-2.6.38-rc6-00039-g61d2fb7
>> [... etc ...]
>> | Found initrd image: /boot/initrd.img-2.6.37-trunk-amd64
>> | File descriptor 4 (pipe:[556425]) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 5 (/var/lib/dpkg/status (deleted)) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 6 (/var/lib/apt/lists/mirrors.kernel.org_debian_dists_squeeze_main_binary-amd64_Packages) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 7 (/var/lib/apt/lists/security.debian.org_dists_squeeze_updates_main_binary-amd64_Packages) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 8 (/var/lib/apt/lists/mirrors.kernel.org_debian_dists_squeeze-proposed-updates_main_binary-amd64_Packages) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 9 (/var/lib/apt/lists/mirrors.kernel.org_debian_dists_sid_main_binary-amd64_Packages) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 10 (/var/lib/apt/lists/mirrors.kernel.org_debian_dists_experimental_main_binary-amd64_Packages) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | File descriptor 11 (/var/lib/cupt/lock) leaked on lvs invocation. Parent PID 17535: /bin/sh
>> | done
>> | (Reading database ... 124124 files and directories currently installed.)
>> 
>> Bugscript output attached.  Any hints for tracking this down? 
>
> Looks to me like cupt's fault for leaking all those fds through to
> subprocesses, rather than marking them close-on-exec.  Do you agree?  If
> so, it should be reassigned to cupt.

Sure, let's try that. :)

Thanks,
Jonathan