On Sun, Mar 11, 2007 at 03:57:10PM -0400, Mike Young wrote:
> So I decided to try some of the other packages that I upgraded 
> previously at the same time.
> They all seemed to go well except for uw-imapd (the one with the error 
> previously).
> This time around there was a more serious error than just openbsd-inetd 
> not restarting.
> uw-imapd hung during its postrm. The actual postrm script went defunct 
> and the parent perl instance had to be killed to get aptitude moving again.
> After killing the uw-imapd install, the openbsd-inetd install failed 
> every time.

> Both uw-imapd and openbsd-inetd can be upgraded by themselves just fine. 
> When they are upgraded together, they cause problems. I have attached my 
> console log.

> Here's what I see happening:
> 1) during removal of openbsd-inetd, we stop the running instance of 
> inetd. - I can confirm this occurs
> 2) during removal of uw-imapd, we invoke update-inetd (postrm), this 
> seems to hang. (I do not remember a hang during my initial report... 
> there was a dpkg error with uw-imapd, but not a hang)
> 3) Step 2 above causes a new instance of inetd to be started - I can 
> confirm this occurs via manually stopping inetd and invoking 
> update-inetd manually
> 4) when openbsd-inetd attempts to start a new process, there is already 
> one running.

Sure enough, I can reproduce this problem here.  Here's what happens for me:

- the old openbsd-inetd's prerm is called, stopping inetd.  this
  deconfigures openbsd-inetd, but does *not* correctly deconfigure netbase
  which depends on it.  (or, the user may have another provider of
  inet-superserver installed, so it's not incorrect to leave netbase
  configured.)
- uw-imapd's dependencies are all satisfied (since netbase was never
  deconfigured), so uw-imapd is configured, which calls update-inetd --add
  and/or update-inetd --enable.
- update-inetd calls invoke-rc.d openbsd-inetd restart, which does not just
  force a reload of the config (like force-reload does), it *starts*
  openbsd-inetd if not already running.
- openbsd-inetd is configured, tries to start its daemon which is already
  running, and fails.

This also explains the hang in uw-imapd's maintainer script; after starting
inetd, the debconf frontend can no longer exit when the postinst has exited
because the inetd process is still attached to that frontend.

Marco, I understand that openbsd-inetd is designed to only run when there
are configured services for it to listen to, but I wonder if that's wise
given that this bug falls out directly from that decision.  If inetd could
be trusted to be running all the time when configured, then "invoke-rc.d
openbsd-inetd force-reload" would be all that update-inetd would ever need,
and inetd would never be started out of order.

Anyway, given that dpkg's behavior doesn't seem to be new and isn't likely
to change before etch, I see two options:

- openbsd-inetd can forcibly stop inetd again in its postinst before
  starting it.
- openbsd-inetd can be changed to always run even when no services are
  configured, and update-inetd can be switched to use force-reload instead
  of restart.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
[EMAIL PROTECTED]                                   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to