Comment 1 for bug 544910

This does not just break upgrading, the same thing happens when installing aiccu on an already-running system.

What seems to be going on is this:

- debconf launches the postinst script, using an extra pipe
  (connected to fd 3 in the script) to communicate.

- The postinst script eventually launches aiccu, which inherits fd 3.

- aiccu daemonizes, keeping fd 3 open.

- The postinst script terminates.

- debconf remains blocked trying to read from the pipe.

That is: I see this from ps:

/usr/bin/dpkg --status-fd 25 --configure aiccu
  /usr/bin/perl -w /usr/share/debconf/frontend /var/lib/dpkg/info/aiccu.postinst configure
    [aiccu.postinst] <defunct>
/usr/sbin/aiccu start

with strace/gdb showing that aiccu is running normally and the perl process is blocked trying to read from a pipe, and /proc telling me that same pipe is connected to fd 3 of the aiccu process. Killing aiccu (killall aiccu or /etc/init.d/aiccu stop) gets debconf unstuck.

As far as I can tell a reasonable way of fixing this is for aiccu to close all its fds when it daemonizes. Some googling indicates you're "supposed" to do that (see for example http://www.python.org/dev/peps/pep-3143/#correct-daemon-behaviour which refers to a book and a couple of implementations). Unfortunately upstream disagrees with me, and I'm not sure where else this could be fixed. Can the postinst script (which does not explicitly use this fd anywhere) reasonably close it somehow? Should invoke-rc.d close all fds? Should /etc/init.d/aiccu?

I will attach the patch doing this in aiccu (the one rejected upstream) here. My ppa ( https://launchpad.net/~marienz/+archive/ppa ) has a build with this patch applied (and a lot of other stuff, so please do not blindly add the entire ppa to get past this bug!)