[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Sven Luther

Reply to: