On Sun, Dec 25, 2005 at 01:50:35PM -0800, Steve Langasek wrote: > On Sun, Dec 25, 2005 at 03:34:43PM +0000, Colin Watson wrote: > > The STOP command causes the debconf frontend to shut down; that would > > certainly break anything trying to talk to debconf after it. May be > > worth removing that and seeing if things start working. > > > I haven't checked if kernel-package runs anything else that would > > require it to use STOP. It seems a little unlikely that it would be > > starting up any daemons, though. Note a common misconception: the STOP > > command does *not* put your file descriptors back the way they were > > before you started the debconf frontend. > > Indeed, not only does STOP not restore your file descriptors, it also leaves > a sentinel value in the environment which prevents debconf-using children > from successfully restarting the frontend. STOP should only be used when > you need to force-kill the frontend because of other processes that will > otherwise leave dangling file descriptors open to it after your scripts > exit.
Ok, then this is probably the root of the problem here. Kernel-package does call db_stop, before calling the hooks, since it has no guarantee that the hooks will behave properly. I understand that the intention of Manoj was to restore the file descriptors in order to have hooks like grub-update be able to send output to stdout, not for the other reason Colin mentioned, having to deal with daemons. Colin could you giive a bit more detail on how this daemon trick works and what the issue is ? Is it possible that a random kernel hook would be starting such a daemon ? right now i don't think this is done, nor is it the job of the kernel hooks, but one never knows, and i believe this has to be properly documented in the kernel-package documentation. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
