Error running shared postrotate script

Ever since upgrading to 1.8.0 I get the following report from Cron:

/etc/cron.daily/logrotate:
error: error running shared postrotate script for '/var/log/nginx/.log

error: error running shared postrotate script for '/var/
www.example.com/logs/
.log ’
run-parts: /etc/cron.daily/logrotate exited with return code 1

Contents of /etc/logrotate.d/nginx:

/var/log/nginx/*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then
run-parts /etc/logrotate.d/httpd-prerotate;
fi;
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
}

/var/www/example.com/logs/*.log {
daily
missingok
rotate 36500
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then
run-parts /etc/logrotate.d/httpd-prerotate;
fi;
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
}

Their are numerous …/example.com/… directories in the config file,
but
I have had this configuration for ages, and the update to 1.8.0 did not
attempt to make any changes to this file.

There is a bug report (dated 2015-05-01) at Launchpad that appears
identical to my issue:
https://bugs.launchpad.net/nginx/+bug/1450770

Are there any workarounds or configuration changes to correct this
issue?

Thanks!

Paul

System configuration:

Ubuntu 12.0.4.5 LTS (GNU/Linux 3.2.0-82-virtual x86_64)

Nginx installed from PPA
https://launchpad.net/~nginx/+archive/ubuntu/stable

nginx -V

built with OpenSSL 1.0.1 14 Mar 2012
TLS SNI support enabled
configure arguments: --with-cc-opt=’-g -O2 -fPIE -fstack-protector
–param=ssp-buffer-size=4 -Wformat -Wformat-security
-Werror=format-security -D_FORTIFY_SOURCE=2’
–with-ld-opt=’-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro
-Wl,-z,now’
–prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
–http-log-path=/var/log/nginx/access.log
–error-log-path=/var/log/nginx/error.log
–lock-path=/var/lock/nginx.lock
–pid-path=/run/nginx.pid
–http-client-body-temp-path=/var/lib/nginx/body
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi
–http-proxy-temp-path=/var/lib/nginx/proxy
–http-scgi-temp-path=/var/lib/nginx/scgi
–http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
–with-ipv6 --with-http_ssl_module --with-http_stub_status_module
–with-http_realip_module --with-http_auth_request_module
–with-http_addition_module --with-http_dav_module
–with-http_geoip_module
–with-http_gunzip_module --with-http_gzip_static_module
–with-http_image_filter_module --with-http_spdy_module
–with-http_sub_module --with-http_xslt_module --with-mail
–with-mail_ssl_module
–add-module=/build/buildd/nginx-1.8.0/debian/modules/nginx-auth-pam
–add-module=/build/buildd/nginx-1.8.0/debian/modules/nginx-dav-ext-module
–add-module=/build/buildd/nginx-1.8.0/debian/modules/nginx-echo
–add-module=/build/buildd/nginx-1.8.0/debian/modules/nginx-upstream-fair
–add-module=/build/buildd/nginx-1.8.0/debian/modules/ngx_http_substitutions_filter_module

On Sun, May 03, 2015 at 09:56:09AM -0700, Paul N. Pace wrote:

Hi there,

Ever since upgrading to 1.8.0 I get the following report from Cron:

I suspect that this problem is outside the nginx binary, but may be due
to other files added as part of the package installation.

/etc/cron.daily/logrotate:
error: error running shared postrotate script for '/var/log/nginx/.log ’
error: error running shared postrotate script for '/var/
www.example.com/logs/
.log ’
run-parts: /etc/cron.daily/logrotate exited with return code 1

What output do you get when running

invoke-rc.d nginx rotate

as the appropriate user?

There is a bug report (dated 2015-05-01) at Launchpad that appears
identical to my issue:
https://bugs.launchpad.net/nginx/+bug/1450770

That bug report asks the same question.

The answer there suggests that something changed in the init script.

Are there any workarounds or configuration changes to correct this issue?

Perhaps revert to the previous init script; perhaps change your
logrotate
script to do what is needed (send a USR1 signal to the nginx master
process) using whatever new means your system provides?

I think that both of those scripts come from the packager, so that might
be the best place to get a “will work on next update” solution.

Good luck with it,

f

Francis D. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs