Re: kernel-package hooks transition
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
Reply to: