On Wed, Aug 04, 2010 at 12:36:00AM +0100, Ben Hutchings wrote: > On Wed, 2010-08-04 at 00:13 +0100, Colin Watson wrote: > > On Mon, Jul 26, 2010 at 03:43:47AM +0100, Ben Hutchings wrote: > > > This seems to be a race condition in debconf, not a bug in the postinst > > > script (which doesn't do anything very interesting). I was able to > > > reproduce it only once. The debconf frontend was blocked on read while > > > the postinst script had exited and was a zombie. > > > > > > (I don't really understand this behaviour as read on a pipe should > > > return as soon as the process at the other end of the pipe exits. So it > > > could even be a bug in the kernel, though that seems unlikely.) > > > > I doubt that this is the problem. What's happening is that > > pawserv.postinst calls update-inetd, which in some circumstances can > > restart inetd. Thus inetd is left holding the debconf pipe open and > > debconf never realises that the postinst has exited. > > That makes sense. > > > The simple fix should be to put 3>&- at the end of each of the > > update-inetd invocations, so that update-inetd is always disconnected > > from debconf. > > This seems like a bug in update-inetd which should not have to be > worked-around in every maintainer script.
I see your point, although I think I could make a reasonably convincing argument either way. The opposing position is that it's the postinst script that's using debconf, not update-inetd, and therefore the postinst should clean up after itself by not passing the extra open fd on to update-inetd. (DebianNet.pm uses debconf, but it uses the Perl bindings, which don't open fd 3 - that hack is specific to the shell confmodule.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
