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.

5
  • 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, 2016 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, 2016 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, 2016 at 0:57
  • Thanks @ThomasWard, pretty sure the question you linked is exactly the same as my second issue.
    – Walf
    Oct 28, 2016 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, 2016 at 1:06

3 Answers 3

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.

2
  • Benefits of having maintainers who frequent AU. :D
    – muru
    Oct 27, 2016 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, 2016 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)

5
  • This also prevents the configuration from doing what it should. I will be poking this today to get fixes out.
    – Thomas Ward
    Oct 27, 2016 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, 2016 at 12:37
  • Considering that that is the core issue of the latest CVE that was patched, skipping is bad
    – Thomas Ward
    Oct 27, 2016 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, 2016 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, 2016 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!

5
  • 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, 2016 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 =]. Oct 27, 2016 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"; Oct 27, 2016 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, 2016 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, 2017 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .