5

I'm on 14.04.5 LTS. I get this error when running a normal apt-get upgrade:

Setting up nginx-common (1.10.1-3+trusty1) ...
dpkg: error processing package nginx-common (--configure):  
 subprocess installed post-installation script returned error exit status 1

I've omitted all the subsequent errors caused by this, "Package nginx-common is not configured yet.", etc.

I followed the process in this answer to debug the .postinst and it never gets beyond the 3rd line: . /usr/share/debconf/confmodule – that's what's returning the 1.

I've tried this solution but it didn't help, debconf is definitely accessible. And these ones (the error persists). I have no ipv6 listen directives in any included conf files as far as I can tell.

I have no clue as to how I'd debug debconf to see why it's failing. Does anyone know what I should try next?


Edit: New updates, they install but I get this error at the end:

Setting up nginx-full (1.10.1-3+trusty2) ...
initctl: invalid command: upgrade
Try `initctl --help' for more information.
invoke-rc.d: initscript nginx, action "upgrade" failed.

Not sure if I should mark as resolved.

  • that update you did sounds like its own unique individual different issue - you should open a new question. I also have a fix in the works for this (it's a completely different issue, so it should be its own question, but it would be closed as a bug report) – Thomas Ward Oct 28 '16 at 0:42
  • 1
    Note that your second issue is actually in this question, and has multiple open bugs: unix.stackexchange.com/questions/209585/… – Thomas Ward Oct 28 '16 at 0:51
  • Note that I have fixes uploaded and pending in the staging PPAs currently - the builders are a little overloaded, and I've slammed them fairly hard today so patience is a virtue (I still suggest splitting the second issue off into it's own question because it's entirely unrelated to the original core issue you've reported) – Thomas Ward Oct 28 '16 at 0:57
  • Thanks @ThomasWard, pretty sure the question you linked is exactly the same as my second issue. – Walf Oct 28 '16 at 1:05
  • actually 100% certain it's the issue you're seeing. Every time the PPAs resync with Debian we lose some distro-specific patches, which includes the patch for this issue. It's why I never closed the logrotate specific bug referenced in the question I linked. – Thomas Ward Oct 28 '16 at 1:06
9

This specific issue is fixed, please update your packages!


Ubuntu Repositories (LP Bug #1637058)

In Ubuntu Zesty's proposed repository (this is an in-development release, I hope you aren't using this...), 1.10.1-0ubuntu5 addresses this issue.

In Ubuntu Trusty, Xenial, and Yakkety, the Security team has released updated versions of the packages to address this issue, and is considering it a regression in the package. This information is detailed in the bug and very briefly in the corresponding Ubuntu Security Notice (USN-3114-2), but this issue is fixed in the following versions of the package:

  • Ubuntu Trusty: 1.4.6-1ubuntu3.7 (Security and Updates repositories)
  • Ubuntu Xenial: 1.10.0-0ubuntu0.16.04.4 (Security and Updates repositories)
  • Ubuntu Yakkety: 1.10.1-0ubuntu1.2 (Security and Updates repositories)

The version in the Ubuntu Precise repositories are not affected, as they were never altered in a way which introduced the CVE which prompted the recent updates. (This only applies to the Ubuntu Repositories, not the PPAs.)


PPAs (LP Bug #1637200)

I have uploaded revised packages to the staging PPA that address this issue, and implement a fix. These built without issue, and were copied to the primary Mainline and Stable PPAs on Launchpad as of 12:56 PM on October 27, 2016 (UTC-04:00).

This includes fixes for Precise, Trusty, Xenial, and Yakkety. The PPAs do not yet have Zesty support.


Obligatory disclosure:

I am the primary person on the Ubuntu Server Team in charge of the nginx packages. I also maintain the PPAs that reside under the team at https://launchpad.net/~nginx.

I also have direct knowledge on this issue, and the process of fixes being made available, because I helped to discover the problem affects the recent Security updates done, and also Debian.

  • Benefits of having maintainers who frequent AU. :D – muru Oct 27 '16 at 16:36
  • 1
    @muru More so you can blame the eighty or so twitter messages and emails I had this morning when I woke up. And the bug reports. And my discovering the problem because I made a mistake applying Debian's patches... which just happened to show the problems here and how to fix it. – Thomas Ward Oct 27 '16 at 16:36
7

Official fixed packages have been released, use those

TL;DR Scroll to the bottom

Just ran into this issue myself.

To debug it a bit further, I set the following environment variable:

export DEBCONF_DEBUG=developer

That way we can see what debconf is doing.

Now we run

dpkg --configure --pending

And we can see the following:

 Setting up nginx-common (1.10.1-3+xenial1) ...
 debconf (developer): frontend started
 debconf (developer): frontend running, package name is nginx-common
 debconf (developer): starting /var/lib/dpkg/info/nginx-common.config configure 1.10.1-3+xenial0
 dpkg: error processing package nginx-common (--configure):
 subprocess installed post-installation script returned error exit status 1
 dpkg: dependency problems prevent configuration of libnginx-mod-http-image-filter:
 libnginx-mod-http-image-filter depends on nginx-common (= 1.10.1-3+xenial1); however:
 Package nginx-common is not configured yet.

Now we can edit the /var/lib/dpkg/info/nginx-common.config script, and change

#!/bin/sh

with

#!/bin/sh -x to enable debugging as well.

Running dpkg --configure --pending again will show:

Setting up nginx-common (1.10.1-3+xenial1) ...
debconf (developer): frontend started
debconf (developer): frontend running, package name is nginx-common
debconf (developer): starting /var/lib/dpkg/info/nginx-common.config configure 1.10.1-3+xenial0
+ set -e
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ logdir=/var/log/nginx
+ log_symlinks_check 1.10.1-3+xenial0
+ [ -z 1.10.1-3+xenial0 ]
+ dpkg --compare-versions 1.10.1-3+xenial0 lt-nl 1.10.1-0ubuntu1.1
+ return
dpkg: error processing package nginx-common (--configure):

And now we can see our problematic line in the script

dpkg --compare-versions 1.10.1-3+xenial0 lt-nl 1.10.1-0ubuntu1.1

returns exit code 1, as it should -- it's doing a version comparison and returns 0 or 1 depending on the result.

I won't comment on how to properly fix it, as it's an actual bug being tracked at #1637058 (for Ubuntu) and #1637200 (for PPAs) at LP.

Work-around fix:

Edit /var/lib/dpkg/info/nginx-common.config

and add a return on the first line of the log_symlinks_check function.

e.g.:

 log_symlinks_check() {
     return                <---- here
     # Skip new installations
     [ -z "$1" ] && return

This will allow the upgrade process to continue.

EDIT As pointed out by @Thomas Ward, this will skip a setup step (fixing insecure symlinks -- if there are any -- in /var/log/nginx)

  • This also prevents the configuration from doing what it should. I will be poking this today to get fixes out. – Thomas Ward Oct 27 '16 at 12:22
  • That is correct, but I think there are very few that have logs symlinked in /var/log/nginx -- and if they do, they probably know how to fix this issue without googling it :) Added it to the answer just in case, thanks for the comment! – Emil Burzo Oct 27 '16 at 12:37
  • Considering that that is the core issue of the latest CVE that was patched, skipping is bad – Thomas Ward Oct 27 '16 at 12:53
  • 1
    FYI, make a note there are two separate tracking bugs for this - one is for Ubuntu (bugs.launchpad.net/ubuntu/+source/nginx/+bug/1637058), and one is for the PPAs (bugs.launchpad.net/nginx/+bug/1637200) – Thomas Ward Oct 27 '16 at 13:42
  • Also note that I think we have a fix that will be usable, both for the Ubuntu updates that went out and the PPAs. Working on testing first. – Thomas Ward Oct 27 '16 at 14:41
6

Having same issue on :

  • 14.04.5 LTS (GNU/Linux 3.13.0-32-generic x86_64)
  • 16.04.1 LTS (GNU/Linux 4.4.0-45-generic x86_64)

Setting up nginx-common (1.10.1-3+trusty1) ... dpkg: error processing package nginx-common (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of libnginx-mod-http-auth-pam: libnginx-mod-http-auth-pam depends on nginx-common (= 1.10.1-3+trusty1); however: Package nginx-common is not configured yet.

dpkg: error processing package libnginx-mod-http-auth-pam (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libnginx-mod-http-echo: libnginx-mod-http-echo depends on nginx-common (= 1.10.1-3+trusty1); however: Package nginx-common is not configured yet.

dpkg: error processing package libnginx-mod-http-echo (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: nginx-common libnginx-mod-http-auth-pam libnginx-mod-http-echo

Solved

I was able to fix the issue by first making a backup of the /etc/nginx folder.

sudo tar -zcf ~/nginx.tgz /etc/nginx

Then I purged anything to do with nginx from the system. I had to do it in step as the dependency issues were triggered.

sudo apt-get purge nginx-full
sudo apt-get purge nginx-common
sudo apt-get purge nginx*

After that, install nginx back onto the system sudo apt-get install nginx-full.

And finally restore the /etc/nginx folder with sudo tar -zxf ~/nginx.tgz and restart nginx using sudo service nginx restart

Hope this helps!

  • 1
    I was trying to avoid purge just because I didn't want to lose all the conf, but this seems like a good work-around to that. – Walf Oct 27 '16 at 3:58
  • @Walf Yeah it wasn't my first choice either but did the job in the end. Have a look at @Emil Bunzos answer further down for a less drastic workaround =]. – Sergei Filippov Oct 27 '16 at 10:04
  • Another possible gothcha is if you're using the dynamic loading modules, these will need to be reconfigured to the reinstalled nginx instance. e.g. load_module "modules/ngx_http_geoip_module.so"; – Sergei Filippov Oct 27 '16 at 10:49
  • 1
    All workarounds should be considered invalidated now - officially fixed packages have been uploaded to the PPAs and the Repositories. – Thomas Ward Oct 27 '16 at 18:34
  • 1
    Thanks so much this worked great for me. I run a variety of tests of my Nginx Bot Blocker on TravisCI and I test it from 1.10 all the way through to 1.3.x but was having issues getting 1.13.x to start / reload due to this service issue. – MitchellK Oct 4 '17 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.