I know I said I wouldn't look into the code, but I couldn't resist...
It seems the problem is in the wait_dpkg() function. There update-menu
forks, the child then does some stuff, sends a signal that should kill
the parent and lets dpkg continue. The child then waits for dpkg to
finish.
Apparently in both cases observed the parent update-menu fails to die
and with that holds the install process. In the case where we see a
<defunct> child update-menu, the child can't get a update-menu lock
(which can happen if another package already fired up an update-menu
instance) and dies as it should. In the case where I saw the child
waiting for the dpkg-lock it could get the update-menu-lock, and sits
there waiting as it should.
Concluding, somehow the parent update-menu never gets the signal or the
signal never gets send. I'm not at the broken machine at the moment, so
I can't test if a 'kill -SIGHUP2 <parentid>' has the desired effect,
will do that tonight.
/ Would be nice if dpkg had support for hooks, )
.oO( then those signals wouldn't be necessary. /
grts Tim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
