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]