Strange log file behavior

Server NGINX
1

I noticed that most of my rotated nginx log files are empty (0 bytes).

My only access_log directive is in nginx.conf:

access_log /var/log/nginx/localhost.access_log combined;

Also nginx is currently logging to
/var/log/nginx/localhost.access_log.1 instead of localhost.access_log.

Does anyone know why these things are happening?

  • Grant
2

Hello!

On Sun, Jul 14, 2013 at 04:44:53AM -0700, Grant wrote:

I noticed that most of my rotated nginx log files are empty (0 bytes).

My only access_log directive is in nginx.conf:

access_log /var/log/nginx/localhost.access_log combined;

Also nginx is currently logging to
/var/log/nginx/localhost.access_log.1 instead of localhost.access_log.

Does anyone know why these things are happening?

This usually happens if someone don’t ask nginx to reopen log
files after a rotation. See here for details:

http://nginx.org/en/docs/control.html#logs

–
Maxim D.
http://nginx.org/en/donation.html

3

This usually happens if someone don’t ask nginx to reopen log
files after a rotation. See here for details:

Controlling nginx

I use logrotate:

/var/log/nginx/*_log {
missingok
sharedscripts
postrotate
test -r /run/nginx.pid && kill -USR1 cat /run/nginx.pid
endscript
}

Does it look OK?

  • Grant
4

Hello!

On Mon, Jul 15, 2013 at 02:49:47AM -0700, Grant wrote:

    postrotate
            test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid`
    endscript

}

Does it look OK?

Make sure paths used in postrotate are correct.

–
Maxim D.
http://nginx.org/en/donation.html

5 
    postrotate
            test -r /run/nginx.pid && kill -USR1 `cat /run/nginx.pid`
    endscript

}

Does it look OK?

Make sure paths used in postrotate are correct.

The paths are correct. I made some tweaks and I’ll report back
tomorrow on how it goes. Any other ideas?

  • Grant
6

affected, too? Which logrotate version do you use?
I’m on Gentoo also and I think you nailed it. I will watch those
bugs. Thank you!

  • Grant
7

This usually happens if someone don’t ask nginx to reopen log
files after a rotation. See here for details:

Controlling nginx

I tried issuing kill -USR1 cat /run/nginx.pid manually but
nginx-1.4.1 still logged to the old file. I got the following in
error_log:

signal 10 (SIGUSR1) received, reopening logs
reopening logs

It does start logging to the new file if I restart nginx afterward. I
also noticed this in error_log from when logrotate executes:

open() “/var/log/nginx/error_log” failed (13: Permission denied)
open() “/var/log/nginx/localhost.access_log” failed (13: Permission
denied)
open() “/var/log/nginx/localhost.error_log” failed (13: Permission
denied)

Is something happening out of order?

  • Grant
8

Hi,

Any other ideas?

Not sure if relevant, but in Gentoo’s bug tracker are some open bugs
regarding current logrotate versions:

https://bugs.gentoo.org/show_bug.cgi?id=476202
https://bugs.gentoo.org/show_bug.cgi?id=474572
https://bugs.gentoo.org/show_bug.cgi?id=476720

Seems to be upstream bugs (not Gentoo specific). So maybe you are
affected, too? Which logrotate version do you use?

–
Regards,
Igor

9

Hi,

you are right. There is a problem:

https://bugs.gentoo.org/show_bug.cgi?id=473036

Upstream (nginx) accepted the report:
http://trac.nginx.org/nginx/ticket/376

–
Regards,
Igor

10

Hello!

On Thu, Jul 18, 2013 at 03:14:10PM +0200, Igor Sverkos wrote:

Hi,

you are right. There is a problem:

473036 – =www-servers/nginx-1.4.1-r2: default permissions of logdir stop logs after SIGUSR1

Upstream (nginx) accepted the report:
http://trac.nginx.org/nginx/ticket/376

The “accepted” part is about future enhancement. The Gentoo part
seems to be about wrong permissions on a log directory, which
result in non-working USR1.

–
Maxim D.
http://nginx.org/en/donation.html

11

you are right. There is a problem:

473036 – =www-servers/nginx-1.4.1-r2: default permissions of logdir stop logs after SIGUSR1

Upstream (nginx) accepted the report:
http://trac.nginx.org/nginx/ticket/376

The “accepted” part is about future enhancement. The Gentoo part
seems to be about wrong permissions on a log directory, which
result in non-working USR1.

It appears you are right. Thank you for clearing that up Maxim.

  • Grant
12

you are right. There is a problem:

473036 – =www-servers/nginx-1.4.1-r2: default permissions of logdir stop logs after SIGUSR1

Upstream (nginx) accepted the report:
#376 (log file reopen should pass opened fd from master process) – nginx

Many thanks Igor! You’ve saved me a lot of trouble.

  • Grant