[Pkg-net-snmp-devel] Bug#453123: Bug#453123: debconf interaction not closed

Ferenc Wagner wferi at niif.hu
Mon Nov 10 21:45:37 UTC 2008


>> Of course not leaking file descriptors is a good practice, but it
>> isn't the responsibility of all the daemons of the world to close all
>> possible file descriptors their parent might have leaked to them (see
>> for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486826#37).
>
> I don't agree here. It is common practice for daemons to close all file
> handles (see http://www.enderunix.org/docs/eng/daemon.php for example).

Hi Jochen,

You are perfectly entitled to do so, I just wanted to point out that
there is another camp.  And it has some valid points, mainly not
wasting a potentially significant amount of resources and masking bugs
in other software (for example, if multipathd had contained such code,
the dpkg error would have remained hidden in the quoted case).

> The patch for 5.4.1 has been accepted by upstream and is included in 5.4.2.

Fine, but the latest Etch security upgrade hung on us again.

>> In my opinion the right fix would be issuing db_stop early in the
>> postinst, before starting the daemons, and depending on that for
>> closing the debconf file descriptors.  I didn't test if that actually
>> happens, but it not, then that's a bug in debconf.
>
> While this is true, i didn't find a clear statement if it's allowed to
> call db_stop before #DEBHELPER# or not. And as upstream accepted the
> patch for snmptrapd, i didn't see a reason to change the script just
> to run into different problems with #DEBHELPER# later.

Well, as I understand it, the #DEBHELPER# section has no grounds to
assume you already sourced confmodule in the first place.

But to fix the hang, it's enough to db_stop at the very end of the
script.  Yes, the daemon would inherit the debconf descriptors in this
case, which is wrong.  But at least the installation would not hang.
-- 
Regards,
Feri.





More information about the Pkg-net-snmp-devel mailing list