>> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
