It seems that when on a system with perl 5.8.0/unstable, frontend do
not detect that a maintainer script has been finished, and so the
debconf/dpkg process remain running in memory, preventing the user to
return to normal bash prompt until he issues two CRTL-C

Debconf seems to work correctly when the same installation action is
performed on a system with perl 5.6

For systems with perl 5.8.0 the maintainer needs to include a final
'db_stop' in any script calling debconf module for the installation to
work properly.

This behaviour has been found trying to install at least the following
packages

  * phpnuke_5.6-4 (note that the actual unstable version 5.6-5 has
    already been patched with the final 'db_stop'

  * postnuke_0.714-1

  * phpgroupware_0.9.14-0.RC3.2 (just on the postrm script)

This behaviour has been found by two maintainers on different computers
(see bug #164148 discussion)

I suspect this behaviour could be found on more packages compiled on
perl 5.6 envirovment and using debconf.

Regards

Hugo Espuny   hec@espuny.net

Debian maintainer for phpnuke and postnuke

hec@espuny.net wrote:

Do these start daemons? Can you find some examples of packages that I can
install to reproduce your problem without waiting an hour on the download
and dragging in tons of random libraries and installing a sql server? If
this is some general problem with perl 5.8 SIGPIPE propigation as you
seem to imply I'd expect that it would break every package; why is it
seemingly limited to php packages? Is there any chance that these
packages' postinsts echo random stuff at stdout and thus confuse
debconf? Where is the DEBCONF_DEBUG transcript that all the debconf
documentation says you should submit with bug reports of this sort?

What do you mean by "compiled on perl 5.6 environment"? None of the
packages you named are compiled against perl at all.

They could restart the webserver throught the wwwconfig-common
interface.

Sorry about that. The SQL server you don't have to be installed. Just the
mysql-client, and then ask debconf not to generate the database.

I have isolate a little bit the problem. It seems to occur only when you
ask debconf to restart the webserver (tested with apache). If you ask
not to configure any webserver, it seems to die properly.
where it dies. Here it goes:

RA:/home/hec# apt-get install phpnuke
Reading Package Lists... Done
Building Dependency Tree... Done
The following NEW packages will be installed:
  phpnuke
  0 packages upgraded, 1 newly installed, 0 to remove and 0  not
  upgraded.
  Need to get 0B/1906kB of archives. After unpacking 11.0MB will be
  used.
  Preconfiguring packages ...
  debconf (developer): starting /tmp/config.87531 configure
  debconf (developer): <-- INPUT medium phpnuke/webserver
  debconf (developer): --> 0 question will be asked
  debconf (developer): <-- INPUT medium phpnuke/dbgeneration
  debconf (developer): --> 0 question will be asked
  debconf (developer): <-- GO
  debconf (developer): --> 0 ok
  debconf (developer): <-- GET phpnuke/dbgeneration
  debconf (developer): --> 0 false
  debconf (developer): <-- INPUT low phpnuke/dbgeneration_negation
  debconf (developer): --> 30 question skipped
  debconf (developer): <-- GO
  debconf (developer): --> 0 ok
  Selecting previously deselected package phpnuke.
  (Reading database ... 38239 files and directories currently
  installed.)
  Unpacking phpnuke (from .../archives/phpnuke_5.6-4_all.deb) ...
  Setting up phpnuke (5.6-4) ...
  debconf (developer): frontend started
  debconf (developer): frontend running, package name is phpnuke
  debconf (developer): starting /var/lib/dpkg/info/phpnuke.config
  configure
  debconf (developer): <-- INPUT medium phpnuke/webserver
  debconf (developer): --> 30 question skipped
  debconf (developer): <-- INPUT medium phpnuke/dbgeneration
  debconf (developer): --> 30 question skipped
  debconf (developer): <-- GO
  debconf (developer): --> 0 ok
  debconf (developer): <-- GET phpnuke/dbgeneration
  debconf (developer): --> 0 false
  debconf (developer): <-- INPUT low phpnuke/dbgeneration_negation
  debconf (developer): --> 30 question skipped
  debconf (developer): <-- GO
  debconf (developer): --> 0 ok
  debconf (developer): starting /var/lib/dpkg/info/phpnuke.postinst
  configure
  debconf (developer): <-- GET phpnuke/webserver
  debconf (developer): --> 0 Apache
  debconf (developer): <-- GET phpnuke/dbadmin
  debconf (developer): --> 0 root
  debconf (developer): <-- GET phpnuke/dbadmpass
  debconf (developer): --> 0
  debconf (developer): <-- RESET phpnuke/dbadmpass
  debconf (developer): --> 0
  debconf (developer): <-- GET phpnuke/dbserver
  debconf (developer): --> 0 localhost
  debconf (developer): <-- GET phpnuke/dbgeneration
  debconf (developer): --> 0 false


And then it dies. If you ask a "ps ax", you'll find

 8738 pts/2    S      0:07 apt-get install phpnuke
 8794 pts/2    S      0:10 /usr/bin/dpkg --configure phpnuke
 8795 pts/2    S      0:09 /usr/bin/perl -w \
  /usr/share/debconf/frontend /var/lib/dpkg/info/phpnuke.postinst \
  configure
 8801 pts/2    Z      0:00 [phpnuke.postins <defunct>]

I just meant 'built and tested on a machine with perl 5.6'. Improper use
of words, i know.

So, as far as i discover by now, it happens only when you say debconf to
restart apache (maybe other webservers) through wwwconfig-common.

I will try to look for same behaviour on other packages restarting
apache by wwwconfig-common and without it.

Regards.

Hugo Espuny

hec@espuny.net wrote:

Then they probably need to tell debconf when to stop. I suppose I'll
merge this with #50595 and unmerge #164354 and reassign that back to
phpgroupware.

Joey Hess wrote:

|
|Then they probably need to tell debconf when to stop. I suppose I'll
|merge this with #50595 and unmerge #164354 and reassign that back to
|phpgroupware.

OK.

I filled the bug against debconf because it seems to weird that this
behaviour just appears when upgraded to perl 5.8.0, but not when
installing on a machine with the previous version of perl.

If you feel that's the way, it's OK with me.

Regards.

Hugo Espuny