On Wed, 2010-08-04 at 03:29 +0100, Colin Watson wrote: > 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.
This seems like a standard part of detaching a daemon from its parent process. But maybe I remember wrongly, in which case it is up to pawserv. Ideally the debconf shell module would set FD_CLOEXEC for fd 3, but that doesn't appear to be possible in a shell script. (In fact SUS says it is unspecified whether extra file descriptors opened with the shell's exec command have FD_CLOEXEC set.) > (DebianNet.pm uses debconf, but it uses the Perl bindings, which don't > open fd 3 - that hack is specific to the shell confmodule.) Yes, I was confused for a short while by that difference. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
