[Pkg-net-snmp-devel] Bug#453123: Bug#453123: debconf interaction not closed
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).
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.
More information about the Pkg-net-snmp-devel