package php7.0-cli 7.0.32-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 4

Bug #1793436 reported by Abhishek
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
php7.0 (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

ucfr: Attempt from package php7.0-cli to take /etc/php/7.0/apache2/php.ini away from package libapache2-mod-php7.0
ucfr: Aborting.
dpkg: error processing package php7.0-cli (--configure):
 subprocess installed post-installation script returned error exit status 4
dpkg: dependency problems prevent configuration of libapache2-mod-php7.0:
 libapache2-mod-php7.0 depends on php7.0-cli; however:
  Package php7.0-cli is not configured yet.

dpkg: error processing package libapache2-mod-php7.0 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of php7.0-fpm:
 php7.0-fpm depends on php7.0-cli; however:
  Package php7.0-cli is not configured yet.

dpkg: error processing package php7.0-fpm (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of php7.0-cgi:
 php7.0-cgi depends on php7.0-cli; however:
  Package php7.0-cli is not configured yet.

dpkg: error processing package php7.0-cgi (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of php7.0:
 php7.0 depends on php7.0-fpm | libapache2-mod-php7.0 | php7.0-cgi; however:
  Package php7.0-fpm is not configured yet.
  Package libapache2-mod-php7.0No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                                                         No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                              No apport report written because MaxReports is reached already
       No apport report written because MaxReports is reached already
                                                                      is not configured yet.
  Package php7.0-cgi is not configured yet.

dpkg: error processing package php7.0 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 php7.0-cli
 libapache2-mod-php7.0
 php7.0-fpm
 php7.0-cgi
 php7.0
E: Sub-process /usr/bin/dpkg returned an error code (1)

ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: php7.0-cli 7.0.32-0ubuntu0.16.04.1
ProcVersionSignature: Ubuntu 4.4.0-135.161-generic 4.4.140
Uname: Linux 4.4.0-135-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Thu Sep 20 10:37:34 2018
DpkgTerminalLog:
 Setting up php7.0-cli (7.0.32-0ubuntu0.16.04.1) ...
 ucfr: Attempt from package php7.0-cli to take /etc/php/7.0/apache2/php.ini away from package libapache2-mod-php7.0
 ucfr: Aborting.
 dpkg: error processing package php7.0-cli (--configure):
  subprocess installed post-installation script returned error exit status 4
ErrorMessage: subprocess installed post-installation script returned error exit status 4
InstallationDate: Installed on 2018-02-13 (218 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
RelatedPackageVersions:
 dpkg 1.18.4ubuntu1.4
 apt 1.2.27
SourcePackage: php7.0
Title: package php7.0-cli 7.0.32-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 4
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Abhishek (abhishek.mettl) wrote :
tags: removed: need-duplicate-check
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

libapache2-mod-php7.0 is depending on php7.0-cli so they should always be installed together and the latter package should be installed first.

They both have a php.ini file, but it would be different.

libapache will always try to provide its bits to is on an install:
  phpini="/etc/php/7.0/apache2/php.ini"
  ucf /usr/lib/php/7.0/php.ini-production $phpini
it then registers itself with the file
  ucfr libapache2-mod-php7.0 $phpini

php7.0-cli essentially does the same calls as above but with package name "php7.0-cli" and the path is different.
  phpini="/etc/php/7.0/cli/php.ini"

I ran an install of the packages on Xenial and it seems to work fine that way:
Setting up php7.0-cli (7.0.32-0ubuntu0.16.04.1) ...
update-alternatives: using /usr/bin/php7.0 to provide /usr/bin/php (php) in auto mode
update-alternatives: using /usr/bin/phar7.0 to provide /usr/bin/phar (phar) in auto mode
update-alternatives: using /usr/bin/phar.phar7.0 to provide /usr/bin/phar.phar (phar.phar) in auto mode
Creating config file /etc/php/7.0/cli/php.ini with new version
Setting up libapache2-mod-php7.0 (7.0.32-0ubuntu0.16.04.1) ...
Creating config file /etc/php/7.0/apache2/php.ini with new version
 Module mpm_event disabled.
Enabling module mpm_prefork.
apache2_switch_mpm Switch to prefork
apache2_invoke: Enable module php7.0

It is not managed by dpkg:
dpkg -S /etc/php/7.0/apache2/php.ini
dpkg-query: no path found matching pattern /etc/php/7.0/apache2/php.ini

But by ucf
# ucfq /etc/php/7.0/apache2/php.ini
Configuration file Package Exists Changed
/etc/php/7.0/apache2/php.ini libapache2-mod-php7 Yes No
# ucfq /etc/php/7.0/cli/php.ini
Configuration file Package Exists Changed
/etc/php/7.0/cli/php.ini php7.0-cli Yes No

The paths to those are static in the postinst files for php7.0-cli and libapache2-mod-php7, there should not be a way for them to conflict.
The only way I can think of you will hit your error being:
"ucfr: Attempt from package php7.0-cli to take /etc/php/7.0/apache2/php.ini away from package libapache2-mod-php7.0"
Is that someone (or a scri?) had accidentially set up symlinks, so that effectively
  /etc/php/7.0/apache2/php.ini
and
  /etc/php/7.0/cli/php.ini
are the same file.

From ucfr man page:
Where Package is the package associated with the configuration file (and, in some sense, its owner), and Path to configuration file is the full path to the location (usually under /etc) where the configuration file lives, and is potentially modified by the end user. Please note that usually this means that we register actual files, and not symbolic links to files. ucfr will follow symbolic links and register the real file, and not the symbolic link.

That said, the only way I can see the error happening is a misconfiguration - the issue should go away when this is resolved on your system.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I'm marking this bug as Incomplete.

If indeed this is a local configuration problem, you can find pointers to get help for this sort of problem here: http://www.ubuntu.com/support/community

Or if you believe that this is really a bug, then you may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem, explain why you believe this is a bug in Ubuntu rather than a problem specific to your system, and then change the bug status back to New.

Changed in php7.0 (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for php7.0 (Ubuntu) because there has been no activity for 60 days.]

Changed in php7.0 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.